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A  Design  Space  and  Design  Rules  for 
User  Interface  Software  Architecture 

Abstract.  The  architecture  of  a  user  interface  software  system  can  be  described 
in  terms  of  a  fairly  small  number  of  key  functional  and  structural  choices.  This 
report  presents  a  "design  space"  that  identifies  these  key  choices  and  classifies 
the  alternatives  available  for  each  choice.  The  design  space  is  a  useful 
framework  for  organizing  and  applying  design  knowledge.  The  report  presents  a 
set  of  design  rules  expressed  in  the  terms  of  the  design  space.  These  rules  can 
help  a  software  designer  to  make  good  structural  choices  based  on  the  functional 
requirements  for  a  user  interface  system.  Extension  of  this  work  might  eventually 
provide  automated  assistance  for  structural  design. 


1.  Introduction 


Software  architecture  is  the  study  of  the  large-scale  structure  and  performance  of  software 
systems  [Shaw  89].  Important  aspects  of  a  system’s  architecture  include  the  division  of 
functions  among  system  modules,  the  means  of  communication  between  modules,  and  the 
representation  of  shared  information.  This  report  describes  the  architecture  of  user  interface 
systems,  using  a  design  space  that  identifies  the  key  architectural  choices  and  classifies  the 
available  alternatives.  The  space  provides  a  framework  for  design  rules  that  can  assist  a 
designer  in  choosing  an  architecture  that  is  appropriate  for  the  functional  requirements  of  a 
new  system.  The  design  space  is  useful  in  its  own  right  as  a  shared  vocabulary  for  describ¬ 
ing  and  understanding  systems. 

This  report  is  a  summary  of  results  from  the  author’s  thesis  [Lane  90a].  It  concentrates  on 
presenting  those  results  that  are  of  interest  to  user  interface  system  builders.  A  companion 
report  argues  that  design  spaces  and  rules  may  be  a  widely  applicable  means  of  expressing 
software  engineering  knowledge  [Lane  90b]. 


1.1.  Rationale 

The  established  fields  of  engineering  have  long  distinguished  between  routine  and  innova¬ 
tive  design  methods.  Routine  design  uses  standardized  methods  to  solve  problems  similar 
to  those  that  have  been  solved  before.  This  process  is  not  expected  to  yield  the  best  pos¬ 
sible  design,  but  rather  to  yield  a  design  that  meets  all  the  stated  requirements  with  mini¬ 
mum  design  effort.  In  contrast,  innovative  design  methods  rely  less  on  prior  practice  than 
on  raw  invention  or  derivation  from  abstract  principles.  Innovative  designs  can  solve  new 
types  of  problems  or  produce  solutions  especially  well-tuned  to  specific  requirements,  but  at 
a  high  design  cost.  Moreover,  innovative  design  is  more  likely  to  fail  to  produce  a  solution 
than  routine  design  (where  a  routine  method  is  applicable).  Engineering  handbooks  (e.g., 
[Perry  84])  exist  primarily  to  support  routine  design.  A  good  handbook  arms  its  user  with  a 
number  of  standard  design  approaches  and  with  knowledge  of  their  strengths  and  limita¬ 
tions. 
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Routine  design  methods  have  benefits  beyond  reducing  initial  design  cost  A  standardized, 
commonly  known  design  method  reduces  the  effort  needed  to  understand  another  person’s 
design;  hence,  maintenance  costs  are  also  reduced.  More  fundamentally,  standardized 
methods  provide  a  context  for  the  creation  and  application  of  knowledge;  this  is  why  a  stan¬ 
dardized  method  is  usually  better  understood  and  more  reliable  than  an  ad  hoc  one.  For 
example,  the  recognition  and  use  of  standard  control  flow  patterns  (conditionals,  iteration, 
and  so  forth)  made  it  possible  for  researchers  to  discover  the  key  properties  of  those  pat¬ 
terns  (e.g.,  invariant  and  termination  conditions  of  loops).  Programmers  now  routinely  use 
this  knowledge  to  produce  better-quality  code  than  was  possible  without  it. 

At  present,  routine  design  is  not  well  practiced  by  software  engineers.  Some  designers  tend 
to  invent  every  system  from  scratch,  while  others  tend  to  reuse  a  familiar  design  regardless 
of  its  suitability.  Both  errors  arise  from  lack  of  a  set  of  standardized  methods.  Handbook¬ 
like  texts  are  now  widely  available  for  selection  of  algorithms  and  data  structures  (e.g., 
[Knuth  73,  Sedgewick  88]),  but  such  handbooks  do  not  yet  exist  for  higher  levels  of  soft¬ 
ware  design.  The  work  reported  here  is  a  start  toward  developing  a  routine  practice  of  soft¬ 
ware  system  architecture,  within  the  limited  domain  of  user  interface  systems. 

The  systems  covered  by  this  study  are  those  whose  main  focus  is  on  providing  an  inter¬ 
active  user  interface  for  some  software  function(s).  This  includes  user  interface  manage¬ 
ment  systems  (UlMSs),  graphics  packages,  user  interface  toolkits,  window  managers,  and 
even  stand-alone  applications  that  have  a  large  user  interface  component.  This  range  is 
large  enough  that  no  single  design  can  cover  all  cases;  hence,  we  must  consider  how  to 
choose  among  alternatives.  At  the  same  time,  the  range  is  not  too  large  to  allow  recognition 
of  common  patterns.  Future  work  may  make  it  possible  to  construct  useful  design  spaces 
for  larger  classes  of  software  systems. 


1.2.  The  Notion  of  a  Design  Space 

The  central  concept  in  this  report  is  that  of  a  multi-dimensional  design  space  that  classifies 
system  architectures.  Each  dimension  of  a  design  space  describes  variation  in  one  system 
characteristic  or  design  choice.  Values  along  a  dimension  correspond  to  alternative  require¬ 
ments  or  design  choices.  For  example,  required  response  time  could  be  a  dimension;  so 
could  the  means  of  interprocess  synchronization  (e.g.,  messages  or  semaphores).  A  spe¬ 
cific  system  design  corresponds  to  a  point  in  the  design  space,  identified  by  the  dimensional 
values  that  correspond  to  its  characteristics  and  structure.  Figure  1-1  illustrates  a  tiny  de¬ 
sign  space. 

A  design  dimension  is  not  necessarily  a  continuous  scale;  in  most  cases  the  sKace  consid¬ 
ers  only  a  few  discrete  alternatives.  For  example,  methods  for  specifying  user  interface 
behavior  include  state  transition  diagrams,  context-free  grammars,  menu  trees,  and  many 
others.  Each  v-r  these  techniques  has  many  small  variations,  so  one  of  the  key  problems  in 
constructing  a  design  space  is  finding  the  most  useful  granularity  of  classification.  Even 
when  a  dimension  is  in  principle  continuous,  one  may  choose  to  aggregate  it  into  a  few 
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Interprocess  synchronization  mechanism 
Figure  1  -1 :  A  Simple  Design  Space 

discrete  values  (e.g.,  "low,"  "medium,"  "high").  This  is  appropriate  when  such  gross  es¬ 
timates  provide  as  much  information  as  one  needs  (or  can  get)  in  the  early  stages  of  design. 

Another  way  in  which  a  design  space  differs  from  geometric  intuition  is  that  the  dimensions 
may  not  be  independent.  In  fact,  it  is  important  to  discover  correlations  between  the  dimen¬ 
sions  in  order  to  create  design  rules  describing  appropriate  and  inappropriate  combinations 
of  choices.  One  empirical  way  of  discovering  such  correlations  is  to  see  whether  successful 
system  designs  cluster  in  some  parts  of  the  space  and  are  absent  from  others. 

A  crucial  part  of  this  approach  is  to  choose  some  dimensions  that  reflect  requirements  or 
evaluation  criteria  (function  and/or  performance),  as  well  as  other  dimensions  that  reflect 
structure  (or  other  available  design  choices).  Then,  the  observed  correlations  and  resulting 
design  rules  can  provide  direct  design  guidance:  they  show  which  design  choices  are  most 
likely  to  meet  the  functional  requirements  for  a  new  system. 


•  System  B 


Messages  Semaphores  Monitors  Rendezvous  Other  None 


1.3.  Related  Work 

The  concept  of  a  design  space  is  far  from  new.  A  seminal  use  is  Bell  and  Newell’s 
taxonomy  of  computer  hardware  structures  [Bell  71].  They  describe  computers  using 
dimensions  such  as  function  (e.g.,  numeric  calculation  or  communication),  instructions  per 
second,  memory  size,  and  hardware-supported  data  types.  A  software-oriented  example  is 
Wegner’s  design  space  for  object-oriented  languages  [Wegner  87]. 

The  domain  covered  by  this  report’s  design  space  is  user  interface  software.  Various 
researchers  have  investigated  individual  aspects  of  user  interface  software  structures.  Most 
prior  work  deals  with  control  flow  patterns  [Hayes  85,  Tanner  83]  or  classification  of  nota¬ 
tions  for  user  interface  appearance  and  behavior  [Green  86,  Myers  89].  Other  workers  have 
made  proposals  for  standard  module  structures  [Dance  87,  Lantz  87].  Hartson  and  Hix  sur¬ 
vey  much  of  the  existing  work  [Hartson  89].  For  the  most  part,  however,  the  user  interface 
research  community  has  neglected  internal  structural  issues  in  favor  of  work  on  selection 
and  description  of  the  external  behavior  of  a  user  interface.  Hence  the  work  reported  here 
provides  a  more  complete  view  of  the  space  of  user  interface  structural  alternatives  than  any 
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prior  work  and,  for  several  of  the  previously  investigated  dimensions,  it  offers  new  classifica¬ 
tions  that  are  more  useful  for  making  structural  decisions. 
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2.  An  Overview  of  the  Design  Space 

This  section  introduces  the  design  space  by  describing  a  dozen  of  its  dimensions.  The  com¬ 
plete  space  includes  nearly  fifty  dimensions,  many  of  which  are  fairly  obvious  to  anyone 
familiar  with  user  interface  software.  To  avoid  bogging  down  in  details,  we  will  consider  only 
the  more  interesting  dimensions.  For  a  complete  description  of  the  space,  see  Appendix  A. 


2.1.  A  Basic  Structural  Model 

To  describe  structural  alternatives,  it  is  necessary  to  have  some  terminology  that  identifies 
components  of  a  system.  The  terminology  must  be  quite  general,  or  it  will  be  inapplicable  to 
some  structures.  A  useful  scheme  for  user  interface  systems  divides  any  complete  system 
into  three  components,  or  groups  of  modules: 

1.  An  application-specific  component:  Code  that  is  specific  to  one  particular 
application  program  and  is  not  intended  to  be  reused  in  other  applications.  In 
particular,  this  component  includes  the  functional  core  of  the  application.  It 
may  also  include  application-specific  user  interface  code.  (The  term  "code* 
should  be  read  as  including  tables,  grammars,  and  other  non  procedural  spec¬ 
ifications,  as  well  as  conventional  programming  methods.) 

2.  A  shared  user  Interface  component:  Code  that  is  intended  to  support  the 
user  interface  of  muli:ole  application  programs.  If  the  software  system  can 
accommodate  differer ;  types  of  I/O  devices,  only  code  that  is  applicable  to  all 
device  types  is  included  here. 

3.  A  device-dependent  component:  Code  that  is  specific  to  a  particular  I/O  de¬ 
vice  class  (and  is  not  application-specific). 

In  a  simple  system,  the  second  or  third  component  might  be  empty:  there  might  be  no 
shared  code  other  than  device  drivers,  or  the  system  might  have  no  provision  for  supporting 
multiple  device  types  (and  hence  no  clear  demarcation  of  device-specific  code). 


r  \ 

Device¬ 

dependent 

component 

V  a 

- - 

Shared 

user 

interface 

component 

f 

Application- 

specific 

component 

W 

Device  interface  Application  interface 

Figure  2-1 :  A  Basic  Structural  Model  for  User  Interface  Software 


The  intermodule  divisions  that  the  design  space  considers  are  the  division  between 
application-specific  code  and  shared  user  interface  code  on  the  one  hand,  and  between 
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device-specific  code  and  shared  us a?  interface  code  on  the  other.  These  revisions  are 
called  the  application  interface  ano  device  interface  respectively.  Figure  2-1  illustrates  the 
structural  model. 

There  is  some  flexfoility  in  divkfing  a  real  systc~  into  these  three  components.  This  ap¬ 
parent  ambiguity  is  /ery  useful,  for  one  can  analy*  e  different  levels  of  the  system  by  adopt¬ 
ing  different  labelings.  For  example,  in  the  X  Window  System  [Scheifler  86],  one  may  ana¬ 
lyze  the  window  server’s  design  by  regardng  everything  outside  the  server  as  application 
specific,  then  cfividng  the  server  into  shared  user  interface  and  device-dependent  levels.  To 
analyze  an  X  toolkit  package,  it  is  more  useful  to  label  the  toolkit  as  the  shared  code,  while 
regaitfing  the  server  as  a  device-specific  black  box. 

2.2.  Functional  Design  Dimensions 

The  functional  dimensions  identify  the  user  interface  system  requirements  that  most  affect 
the  system’s  structure.  These  dimensions  are  not  intended  to  correspond  to  the  earliest 
requirements  that  one  might  write  for  a  system,  but  rather  to  identify  the  specifications  that 
immediately  precede  the  gross  structural  design  phase.  Thus,  some  design  decisions  have 
already  been  made  in  arriving  at  these  choices. 

The  first  example  of  a  functional  dimension  is  command  execution  time.  This  dimension 
indicates  how  long  the  application  program  may  take  to  process  a  command,  compared  with 
the  reaction  time  of  a  human  user.  Useful  classifications  are: 

•  Short  maximum  time:  All  commands  can  be  executed  in  a  short  time,  say  a 
few  tenths  of  a  second. 

•  Intermediate  maximum,  short  average:  Most  commands  are  executed  in  a 
short  time,  but  some  may  take  a  *:it  longer,  up  to  a  couple  of  seconds. 

•  Long  maximum  time:  Some  or  all  commands  may  take  a  long  time  to  execute 
so  that  the  user  will  have  a  strong  perception  of  waiting. 

As  an  example  of  the  importance  of  command  execution  time,  a  system  in  the  first  category 
can  probably  dispense  with  handling  asynchronous  input  (i.e.,  no  type-ahead  or  command 
cancellation  features).  This  is  less  likely  to  be  appropriate  when  long-running  commands 
are  present. 

The  second  example  functional  dimension  is  external  event  handling:  does  the  application 
program  need  to  respond  to  external  events,  that  is,  events  not  originating  in  the  user  inter¬ 
face?  If  so,  on  what  time  scale? 

•  No  external  events:  The  application  is  uninfluenced  by  external  events,  or 
checks  for  them  only  as  part  of  executing  specific  user  commands.  For  ex¬ 
ample,  a  mail  program  might  check  for  new  mail,  but  only  when  an  explicit  com¬ 
mand  to  do  so  is  given.  In  this  case,  no  support  for  external  events  is  needed 
in  the  user  interface. 

•  Process  events  while  waiting  for  Input:  The  application  must  handle  exter- 
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nai  events,  but  response  time  requirements  are  not  so  stringent  that  it  must  in¬ 
terrupt  processing  of  user  commands.  It  is  sufficient  for  the  user  interface  to 
allow  response  to  external  events  while  waiting  for  input 

•  External  events  preempt  user  commands:  External  event  servicing  has  suf¬ 
ficiently  high  priority  that  user  command  execution  must  be  interrupted  when  an 
external  event  occurs. 

Like  the  previous  dimension,  external  event  handing  has  obvious  implications  for  control 
flow  within  the  user  interface  and  application. 

The  third  example  of  a  functional  dimension  is  user  Interface  adaptability  across  devices. 
This  dimension  measures  how  much  change  in  user  interface  behavior  may  be  required 
when  changing  to  a  different  set  of  I/O  devices: 

•  None:  All  aspects  of  behavior  are  the  same  across  all  supported  devices. 

(This  includes  the  case  that  only  one  set  of  I/O  devices  is  supported.) 

•  Local  behavior  changes:  Only  changes  in  small  details  of  behavior  across 
devices;  for  example,  the  appearance  of  menus. 

•  Global  behavior  changes:  Major  changes  in  surface  user  interface  behavior; 
for  example,  a  change  between  menu-driven  and  command-language  interface 
types. 

•  Application  semantics  changes:  Changes  in  underlying  semantics  of  com¬ 
mands  (e.g.,  continuous  display  of  state  versus  display  on  command). 

The  final  examples  are  a  complementary  pair  of  dimensions.  Application  portability 
across  Interaction  styles  specifies  the  degree  of  portability  across  interaction  styles  re¬ 
quired  for  applications  that  will  use  the  user  interface  software: 

•  High:  Applications  should  be  portable  across  significantly  different  styles  (e.g., 
command  language  versus  menu-driven). 

•  Medium:  Applications  should  be  independent  of  minor  stylistic  variations  (e.g., 
menu  appearance). 

•  Low:  User  interface  variability  is  not  a  concern,  or  application  changes  are  ac¬ 
ceptable  when  modifying  the  user  interface. 

User  interface  system  adaptability  across  interaction  styles  specifies  how  adaptable  to 
different  interaction  styles  the  shared  user  interface  software  should  be: 

•  High:  Adaptable  to  a  wide  range  of  interface  styles. 

•  Medium:  Limited  adaptability. 

•  Low:  Imposes  a  specific  interface  style. 

Since  interface  behavior  must  be  specified  somewhere,  there  is  a  tradeoff  between  appli¬ 
cation  and  shared  user  interface  flexibility:  either  the  shared  software  imposes  a  stylistic 
decision,  or  the  application  makes  the  decision  and  hence  becomes  less  portable.  This 
dilemma  can  be  alleviated  by  wise  use  of  default  choices,  but  in  general,  high  requirements 
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for  both  of  these  dimensions  should  be  viewed  with  suspicion,  in  the  other  direction,  low 
requirements  for  both  dimensions  kxScate  little  flexibility  in  user  interface  behavior,  which  is 
perfectly  appropriate  for  some  systems  (for  example,  if  strong  user  interface  conventions 
exist). 
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2.2.1.  The  Most  Important  Functional  Dimensions 

It  is  reasonable  to  expect  that  some  functional  dimensions  have  more  influence  on  structure 
than  others,  but  it  is  difficult  to  guess  which  ones  have  the  greatest  impact.  Some  insight 
can  be  gained  from  the  author’s  experiments  with  automated  design  rules  (see  Section  4): 
we  can  rank  file  functional  dimensions  according  to  the  total  weight  given  to  each  in  the 
automated  rule  set.  (Those  rules  did  not  fully  reproduce  the  decisions  of  human  experts,  so 
this  ranking  may  need  to  be  modified  when  better  data  is  available.)  On  this  basis,  the  five 
functional  dimensions  with  most  influence  on  the  structural  dimensions  are: 

•  User  interface  system  adaptability  across  devices 

•  Application  portability  across  devices 

•  Application  portability  across  interaction  styles 

•  Basic  interface  class 

•  System  organization 
The  next  five  dimensions  are: 

•  Available  processing  power 

•  I/O  device  class  breadth 

•  User  interface  system  adaptability  across  interaction  styles 

•  User  customizability 

•  External  event  handling 

The  remaining  fifteen  functional  dimensions  (listed  in  Appendix  A)  have  less  influence  on 
structure. 

The  most  striking  feature  of  this  ranking  is  the  importance  of  dimensions  having  to  do  with 
flexibility.  Evidently  the  nature  and  degree  of  adaptability  required  of  the  system  are  by  far 
the  most  important  determinants  of  an  appropriate  structure.  It  is  an  open  question  whether 
this  property  is  unique  to  user  interface  system  structures,  or  is  true  for  other  kinds  of  soft¬ 
ware  as  well. 
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2.3.  Structural  Design  Dimensions 

This  section  presents  some  important  structural  dimensions:  the  fundamental  decisions 
about  system  structure. 

Application  interface  abstraction  level  is  in  many  ways  the  key  structural  dimension.  The 
design  space  identifies  six  general  classes  of  application  interface,  which  are  most  easily 
distinguished  by  the  level  of  abstraction  in  communication:1 

•  Monolithic  program:  There  is  no  separation  between  application-specific  and 
shared  code,  hence  no  application  interface  (and  no  device  interface,  either). 

This  can  be  an  appropriate  solution  in  small,  specialized  systems  where  the  ap¬ 
plication  needs  considerable  control  over  user  interface  details  and/or  little 
processing  power  is  available.  (Video  games  are  a  typical  example.) 

•  Abstract  device:  The  shared  code  is  simply  a  device  driver,  presenting  an 
abstract  device  for  manipulation  by  the  application.  The  operations  provided 
have  specific  physical  interpretations  (e.g.,  "draw  line,"  but  not  "present  menu”). 

Most  aspects  of  interactive  behavior  are  under  the  control  of  the  application, 
although  some  local  interactions  may  be  handled  by  the  shared  code  (e.g., 
character  echoing  and  backspace  handling  in  a  keyboard/display  driver).  In  this 
category,  the  application  interface  and  device  interface  are  the  same. 

•  Toolkit:  The  shared  code  provides  a  library  of  interaction  techniques  (e.g., 
menu  or  scroll  bar  handlers).  The  application  is  responsible  for  selecting  appro¬ 
priate  toolkit  elements  and  composing  them  into  a  complete  interface;  hence 
the  shared  code  can  control  only  local  aspects  of  user  interface  style,  with 
global  behavior  remaining  under  application  control.  The  interaction  between 
application  and  shared  code  is  in  terms  of  specific  interactive  techniques  (e.g., 
"obtain  menu  selection").  The  application  can  bypass  the  toolkit,  reaching 
down  to  an  underlying  abstract  device  level,  if  it  requires  an  interaction  tech¬ 
nique  not  provided  by  the  toolkit.  In  particular,  conversions  between  special¬ 
ized  application  data  types  and  their  device-oriented  representations  are  done 
by  the  application,  accessing  the  underlying  abstract  device  directly.2 

•  Interaction  manager  with  fixed  data  types:  The  shared  code  controls  both 
local  and  global  interaction  sequences  and  stylistic  decisions.  Its  interaction 
with  the  application  is  expressed  in  terms  of  abstract  information  transfers,  such 
as  "get  command"  or  "present  result"  (notice  that  no  particular  external  repre¬ 
sentation  is  implied).  These  abstract  transfers  use  a  fixed  set  of  standard  data 
types  (e.g.,  integers,  strings);  the  application  must  express  its  input  and  output 
in  terms  of  the  standard  data  types.  Hence  some  aspects  of  the  conversion 
between  application  internal  data  formats  and  user-visible  representations 
remain  in  the  application  code. 


’Recognition  of  abstraction  level  as  a  key  property  in  user  interfaces  goes  back  at  least  to  Hayes  et  al  [Hayes 
85].  The  classification  used  here  is  a  practical  one,  but  it  is  based  on  the  theoretical  distinctions  made  by  Hayes. 

2The  notion  that  conversion  between  internal  and  external  representations  of  data  types  is  a  key  activity  in 
user  interfaces  is  duo  to  Shaw  [Shaw  86]. 
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•  Interaction  manager  with  extensible  data  types:  As  above,  but  the  set  of 
data  types  used  for  abstract  communication  can  be  extended.  The  application 
does  so  by  specifying  (in  some  notation)  the  input  and  output  conversions  re¬ 
quired  for  the  new  data  types.  If  properly  used,  this  approach  allows  knowledge 
of  the  external  representation  to  be  separated  from  the  main  body  of  the  appli¬ 
cation. 

•  Extensible  interaction  manager:  Communication  between  the  application 
and  shared  code  is  again  in  terms  of  abstract  information  transfers.  The  inter¬ 
action  manager  provides  extensive  opportunities  for  application-specific  cus¬ 
tomization,  This  is  accomplished  by  supplying  code  that  augments  or  overrides 
selected  internal  operations  of  the  interaction  manager.  (Most  existing  systems 
of  this  class  are  coded  in  an  object-oriented  language,  and  the  language’s  in¬ 
heritance  mechanism  is  used  to  control  customization.)  Usually  a  significant 
body  of  application-specific  code  customizes  the  interaction  manager;  this  code 
is  much  more  tightly  coupled  to  the  internal  details  of  the  interaction  manager 
than  is  the  case  with  clients  of  nonextensible  interaction  managers. 

This  classification  turns  out  to  be  sufficient  to  predict  most  aspects  of  the  application  inter¬ 
face,  including  the  division  of  user  interface  functions,  the  type  and  extent  of  application 
knowledge  made  available  to  the  shared  user  interface  code,  and  the  kinds  of  data  types 
used  in  communication.  For  instance,  we  have  already  suggested  the  division  of  local  ver¬ 
sus  global  control  of  interactive  behavior  that  is  typically  found  in  each  category. 

Abstract  device  variability  is  the  key  dimension  describing  the  device  interface.  We  view 
the  device  interface  as  defining  an  abstract  device  for  the  device-independent  code  to  ma¬ 
nipulate.  The  design  space  classifies  abstract  devices  according  to  the  degree  of  variability 
perceived  by  the  device-independent  code: 

•  Ideal  device:  The  provided  operations  and  their  results  are  well  specified  in 
terms  of  an  "ideal"  device;  the  real  device  is  expected  to  approximate  the  ideal 
behavior  fairly  closely.  (An  example  is  the  PostScript  imaging  model,  which  ig¬ 
nores  the  limited  resolution  of  real  printers  and  displays  [Adobe  85].)  In  this 
approach,  all  questions  of  device  variability  are  hidden  from  software  above  the 
device  driver  level,  so  application  portability  is  high.  This  approach  is  most  use¬ 
ful  where  the  real  devices  deviate  only  slightly  from  the  ideal  model,  or  at  least 
not  in  ways  that  require  rethinking  of  user  interface  behavior. 

•  Parameterized  device:  A  class  of  devices  is  covered,  differing  in  specified 
parameters  such  as  screen  size,  number  of  colors,  number  of  mouse  buttons, 
etc.  The  device-independent  code  can  inquire  about  the  parameter  values  for 
the  particular  device  at  hand,  and  adapt  its  behavior  as  necessary.  Operations 
and  their  results  are  well  specified,  but  depend  on  parameter  values.  (An  ex¬ 
ample  is  the  X  Windows  graphics  model,  which  exposes  display  resolution  and 
color  handling  [Scheifler  86].)  The  advantage  of  this  approach  is  that  higher 
level  code  has  both  more  knowledge  of  acceptable  tradeoffs  and  more  flexibility 
in  changing  its  behavior  than  is  possible  for  a  device  driver.  The  drawback  is 
that  device-independent  code  may  have  to  perform  complex  case  analysis  in 
order  to  handle  the  full  range  of  supported  devices.  If  this  must  be  done  in 
each  application,  the  cost  is  high  and  there  is  a  great  risk  that  programmers  will 
omit  support  for  some  devices.  To  reduce  this  temptation,  it  is  best  to  design  a 
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parameterized  model  to  have  just  a  few  well-defined  levels  of  capability,  so  as 
to  reduce  the  number  of  cases  to  be  considered. 

•  Device  with  variable  operations:  A  well-defined  set  of  device  operations  ex¬ 
ists,  but  the  device-dependent  code  has  considerable  leeway  in  choosing  how 
to  implement  the  operations;  device-independent  code  is  discouraged  from 
being  closely  concerned  with  the  exact  external  behavior.  Results  of  operations 
are  thus  not  well  specified.  (For  example,  GKS  logical  input  devices  [Rosenthal 
82]  and  the  Scribe  formatting  model  [Reid  80].)  This  approach  works  best 
when  the  device  operations  are  chosen  at  a  level  of  abstraction  high  enough  to 
give  the  device  driver  considerable  freedom  of  choice.  Hence  the  device¬ 
independent  code  must  be  willing  to  give  up  much  control  of  user  interface  de¬ 
tails.  This  restriction  means  that  direct  manipulation  (with  its  heavy  depend¬ 
ence  on  semantically-controlled  feedback)  is  not  well  supported. 

•  Ad-hoc  device:  In  many  real  systems,  the  abstract  device  definition  has  devel¬ 
oped  in  an  ad-hoc  fashion,  and  so  it  is  not  tightly  specified;  behavior  varies  from 
device  to  device.  Applications  therefore  must  confine  themselves  to  a  rather 
small  set  of  device  semantics  if  they  wish  to  achieve  portability,  even  though 
any  particular  implementation  of  the  abstract  device  may  provide  many  addi¬ 
tional  features.  (Alphanumeric  terminals  are  an  excellent  example.)  While  aes¬ 
thetically  displeasing,  this  approach  has  one  redeeming  benefit:  applications 
that  do  not  care  about  portability  are  not  hindered  from  exploiting  the  full  capa¬ 
bilities  of  a  particular  real  device. 

These  categories  lend  themselves  to  different  situations.  For  example,  abstract  devices 
with  variable  operations  are  useful  when  much  of  the  system’s  "intelligence"  is  to  be  put  into 
the  device-specific  layer;  but  they  are  only  appropriate  for  handling  local  changes  in  user 
interface  behavior  across  devices. 

Notation  for  user  interface  definition  classifies  the  techniques  used  for  defining  user  inter¬ 
face  appearance  and  behavior: 

•  Implicit  In  shared  user  interface  code:  Information  "wired  into"  shared  code. 

For  example,  the  visual  appearance  of  a  menu  might  be  implicit  in  the  menu 
routines  supplied  by  a  toolkit.  In  systems  where  strong  user  interface  conven¬ 
tions  exist,  this  is  a  perfectly  acceptable  approach. 

•  Implicit  In  application  code:  Information  buried  in  the  application  and  not 
readily  available  to  shared  user  interface  code.  This  is  most  appropriate  where 
the  application  is  already  tightly  involved  in  the  user  interface,  for  example,  in 
handling  semantic  feedback  in  direct  manipulation  systems. 

•  External  declarative  notation:  A  nonprocedural  specification  separate  from 
the  body  of  the  application  program,  for  example,  a  grammar  or  tabular  specifi¬ 
cation.  External  declarative  notations  are  particularly  well  suited  to  supporting 
user  customization  and  to  use  by  nonprogramming  user  interface  experts. 
Graphical  specification  methods  are  an  important  special  case. 

•  External  procedural  notation:  A  procedural  specification  separate  from  the 
body  of  the  application  program;  often  cast  in  a  specialized  programming  lan¬ 
guage,  Procedural  notations  are  more  flexible  than  declarative  ones,  but  are 
harder  to  use.  User-accessible  procedural  mechanisms,  such  as  macro  defini- 
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tion  capability  or  the  programming  language  of  EMACS-like  editors  [Borenstein 
88],  provide  very  powerful  customization  possibilities  for  sophisticated  users. 
However,  an  external  notation  by  definition  has  limited  access  to  the  state  of 
the  application  program,  which  may  restrict  its  capability. 

•  Internal  declarative  notation:  A  nonprocedural  specification  within  the  appli- 
cation  program.  This  differs  from  an  implicit  representation  in  that  it  is  available 
for  use  by  the  shared  user  interface  code.  Parameters  supplied  to  shared  user 
interface  routines  often  amount  to  an  internal  declarative  notation.  An  example 
is  a  list  of  menu  entries  provided  to  a  toolkit  menu  routine. 

•  Internal  procedural  notation:  A  procedural  specification  within  the  application 
program.  This  differs  from  an  implicit  representation  in  that  it  is  available  for 
use  by  the  shared  user  interface  code.  A  typical  example  is  a  status-inquiry  or 
data  transformation  function  that  is  provided  for  the  user  interface  code  to  call. 

This  is  the  most  commonly  used  notation  for  customization  of  extensible  inter¬ 
action  managers.  It  provides  an  efficient  and  flexible  notation,  but  is  not  acces¬ 
sible  to  the  end  user,  and  so  is  useless  for  user  customization.  It  is  particularly 
useful  for  handling  application-specific  feedback  in  direct  manipulation  inter¬ 
faces,  since  it  has  both  adequate  flexibility  and  efficient  access  to  application 
semantics. 

Each  of  these  categories  offers  a  different  tradeoff  between  power,  runtime  cost,  ease  of 
use,  and  ease  of  modification.  For  example,  declarative  notations  are  the  easiest  to  use 
(especially  for  nonprogramming  user  interface  designers)  but  have  the  least  power,  since 
they  can  only  represent  a  predetermined  range  of  possibilities.  Typically,  several  notational 
techniques  are  used  in  a  system,  with  different  aspects  of  the  user  interface  controlled  by 
different  techniques.  For  example,  the  position  and  size  of  a  screen  button  might  be  speci¬ 
fied  graphically,  while  its  highlighting  behavior  is  specified  implicitly  by  the  code  of  a  toolkit 
routine. 

Application  control  flow  indicates  where  Input  processing  occurs  in  the  application’s  flow 
of  control: 

•  Single  Input  point:  The  system  contains  an  event  loop  that  is  the  sole  point  at 
which  user  input  is  accepted;  when  an  input  event  is  received,  it  is  processed; 
then  control  returns  to  the  event  loop  to  await  the  next  input.  Note  that  the 
event  loop  may  be  in  either  application  or  shared  code. 

•  Multiple  Input  point:  Input  is  accepted  at  multiple  points  in  the  application’s 
flow  of  control.  (Usually,  each  such  point  can  handle  only  a  subset  of  the  pos¬ 
sible  inputs,  leading  to  modal  interface  behavior.) 

This  classification  is  a  variation  of  the  standard  distinction  between  "internal  control" 
(application  calls  user  interface)  and  "external  control"  (user  interface  calls  application) 
[Hayes  85,  Tanner  83].  The  standard  terminology  is  unsatisfactory  because  the  properties 
usually  associated  with  external  control  actually  apply  to  any  system  using  an  event  loop, 
regardless  of  the  direction  of  subroutine  calls. 

Number  of  control  threads  indicates  how  many  logical  threads  of  control  exist  in  the  appli¬ 
cation  and  user  interface: 
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•  Single  thread  of  control. 

•  One  user  interface  thread  and  one  application  thread. 

•  Multiple  user  interface  threads  and  one  application  thread. 

•  One  user  interface  thread  and  multiple  application  threads. 

•  Multiple  user  interface  threads  and  multiple  application  threads. 

Multiple  threads  are  useful  for  dealing  with  external  events  or  logically  independent  concur¬ 
rent  dialogues  (e.g.,  multiple  input  devices).  The  one-plus-one-thread  choice  is  particularly 
simple  and  helpful  for  decoupling  application  processing  (including  external  event  handling) 
from  user  interface  logic. 

Control  thread  mechanism  describes  the  method,  if  any,  used  to  support  multiple  logical 
threads  of  control.  Often,  full-fledged  processes  are  too  difficult  to  implement  or  impose  too 
much  overhead,  so  many  partial  implementations  are  used.  This  dimension  classifies  the 
possibilities  as  follows: 

•  None:  Only  a  single  logical  control  thread  is  used. 

•  Standard  processes:  Independently  scheduled  entities  with  interprocess  pro¬ 
tection  (typically,  separate  address  spaces).  These  provide  security  against 
other  processes,  but  interprocess  communication  is  relatively  expensive.  For  a 
user  interface  system,  security  may  or  may  not  be  a  concern,  while  communi¬ 
cation  costs  are  almost  always  a  major  concern.  In  network  environments, 
standard  processes  are  usually  the  only  kind  that  can  be  executed  on  different 
machines. 

•  Llghtwelgnf  processes:  Independently  scheduled  entities  within  a  shared  ad¬ 
dress  space.  These  are  only  suitable  for  mutually  trusting  processes  due  to 
lack  of  security;  but  often  that  is  not  a  problem  for  user  interface  systems.  The 
benefit  is  substantially  reduced  cost  of  communication,  especially  for  use  of 
shared  variables.  Few  operating  systems  provide  lightweight  processes,  and 
building  one’s  own  lightweight  process  mechanism  can  be  difficult. 

•  Non-preemptlve  processes:  Processes  without  preemptive  scheduling  (must 
explicitly  yield  control),  usually  in  a  shared  address  space.  These  are  relatively 
simple  to  implement.  Guaranteeing  short  response  time  is  difficult  and  impacts 
the  entire  system:  long  computations  must  be  broken  up  explicitly. 

•  Event  handlers:  Pseudo-processes  which  are  invoked  via  a  series  of  sub¬ 
routine  calls;  each  such  call  must  return  before  another  event  handler  process 
can  be  executed.  Hence  control  flow  is  restricted;  in  particular,  waiting  for 
another  process  cannot  occur  inside  a  subroutine  called  by  an  event  handler. 

Again,  response  time  constraints  require  system-wide  attention.  The  main  ad¬ 
vantage  of  this  method  is  that  it  requires  virtually  no  support  mechanism. 

•  Interrupt  service  routines:  Hardware-level  event  handling;  a  series  of  inter¬ 
rupt  service  routine  executions  form  a  control  thread,  but  one  with  restricted 
control  flow  and  communication  abilities.  The  control  flow  restrictions  are  com¬ 
parable  to  event  handlers;  but  unlike  event  handlers,  preemptive  scheduling  is 
available. 
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Event  handlers  are  easily  implemented  within  a  user  interface  system;  non-preemptive  proc¬ 
esses  are  harder  but  can  still  be  implemented  without  operating  system  support.  The  other 
mechanisms  usually  must  be  provided  by  the  operating  system.  Some  form  of  preemptive 
scheduling  is  often  desirable  to  reduce  timing  dependencies  between  threads. 

Basis  of  communication  classifies  systems  according  to  whether  communication  between 
modules  depends  upon  shared  state,  upon  events,  or  both.  An  event  is  a  transfer  of  infor¬ 
mation  occurring  at  a  discrete  time,  for  example,  via  a  procedure  call  or  message.  Commu¬ 
nication  through  shared  state  variables  is  significantly  different,  because  the  recipient  al¬ 
ways  has  access  to  the  current  values  and  need  not  use  information  in  the  same  order  in 
which  it  is  sent.  The  design  space  recognizes  four  categories: 

•  Events:  There  is  no  shared  state;  all  communication  relies  on  events. 

•  Pure  state:  Communication  is  strictly  via  shared  state;  the  recipient  must 
repeatedly  inspect  the  state  variables  to  detect  changes. 

•  State  with  hints:  Communication  is  via  shared  state,  but  the  recipient  is  ac¬ 
tively  informed  of  changes  via  an  event  mechanism;  hence  polling  of  the  state 
is  not  required.  However,  the  recipient  could  ignore  the  events  and  reconstruct 
all  necessary  information  from  the  shared  state;  so  the  events  are  efficiency 
hints  rather  than  essential  information. 

•  State  plus  events:  Both  shared  state  and  events  are  used;  the  events  are 
crucial  because  they  provide  information  not  available  from  state  monitoring. 

State-based  mechanisms  are  popular  for  dealing  with  incrementally  updated  displays.  The 
hybrid  state/event  categories  provide  possibilities  for  performance  optimization  in  return  for 
their  extra  complexity.  State-based  communication  requires  access  to  shared  storage, 
which  may  be  impossible  or  unreasonably  expensive  in  some  system  architectures. 

It  is  possible  for  different  bases  of  communication  to  be  used  at  the  application  and  device 
interfaces,  but  this  is  rare.  It  is  fairly  common  to  have  different  bases  of  communication  for 
input  and  output;  hence  the  design  space  provides  separate  dimensions  for  input  and  output 
communication  basis. 
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3.  Design  Rules  for  User  Interface  Systems 

This  section  presents  some  design  rules  that  relate  the  functional  and  structural  dimensions 
of  the  design  space.  Again,  we  will  consider  only  a  few  sample  rules  to  illustrate  the  flavor 
of  the  approach.  For  a  more  thorough  presentation  of  the  rules,  see  Appendix  B. 

Both  here  and  in  Appendix  B,  we  present  the  rules  in  an  informal  fashion.  In  this  form,  the 
rules  are  directly  useful  as  guidelines  or  rules  of  thumb  for  a  human  designer.  Section  4 
describes  how  the  rules  can  be  made  more  formal  and  suitable  for  use  in  automated  design. 

•  Stronger  requirements  for  user  interface  adaptability  across  devices  favor 
higher  levels  of  application  interface  abstraction,  so  as  to  decouple  the  appli¬ 
cation  from  user  interface  details  that  may  change  across  devices.  If  the  re¬ 
quirement  is  for  global  behavior  or  application  semantics  changes,  then 
parameterized  abstract  devices  are  also  favored.  Such  changes  generally  have 
to  be  implemented  in  shared  user  interface  code  or  application  code,  rather 
than  in  the  device  driver;  so  information  about  the  device  at  hand  cannot  be 
hidden  from  the  higher  levels,  as  the  other  classes  of  abstract  device  try  to  do. 
However,  a  requirement  for  local  behavior  changes  can  favor  abstract  devices 
with  variable  operations,  since  this  method  can  allow  all  of  the  required  adap¬ 
tation  to  be  hidden  within  the  device  driver. 

•  High  user  customizability  requirements  favor  external  notations  for  user  inter¬ 
face  behavior.  Implicit  and  internal  notations  are  usually  more  difficult  to  ac¬ 
cess  and  more  closely  coupled  to  application  logic  than  are  external  notations. 

•  A  high  requirement  for  application  portability  across  user  interface  styles  favors 
the  higher  levels  of  application  interface  abstraction.  Less  obviously,  it  favors 
event-based  or  pure  state-based  communication  over  the  hybrid  forms  (state 
with  hints  or  state  plus  events).  A  hybrid  communication  protocol  is  normally 
tuned  to  particular  communication  patterns,  which  may  change  when  user  inter¬ 
face  style  changes. 

•  If  the  maximum  command  execution  time  is  short,  a  single  thread  of  control  is 
practical  and  is  favored  as  the  simplest  solution.  With  longer  commands,  multi¬ 
ple  threads  are  favored  to  permit  user  input  processing  to  continue;  this  is  nec¬ 
essary  to  support  command  cancellation,  for  example. 

•  If  external  events  must  be  handled,  it  is  often  worthwhile  to  provide  separate 
control  thread(s)  for  this  purpose.  Separate  threads  serve  to  decouple  event 
handling  logic  from  user  interface  logic.  When  external  event  handling  requires 
preemption  of  user  commands,  a  preemptive  control  thread  mechanism 
(standard  processes,  lightweight  processes,  or  interrupt  service  routines)  is 
strongly  favored.  Without  such  a  mechanism,  very  severe  constraints  must  be 
placed  on  all  user  interface  and  application  processing  in  order  to  guarantee 
adequate  response  time. 

•  The  most  commonly  useful  control  thread  mechanisms  are  standard  processes, 
lightweight  processes,  and  event  handlers;  the  others  are  appropriate  only  in 
special  cases.  For  most  user  interface  work,  lightweight  processes  are  very 
appropriate  if  available.  Standard  processes  should  be  used  when  protection 
considerations  warrant,  and  in  network  environments  where  it  may  be  useful  to 
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put  the  processes  on  separate  machines.  If  these  conditions  do  not  apply, 
event  handlers  are  the  best  choice  when  their  response  time  limitations  are  ac¬ 
ceptable;  otherwise  it  is  probably  best  to  invest  in  building  a  lightweight  process 
mechanism. 

The  preceding  rules  all  relate  functional  to  structural  dimensions.  Following  is  an  example 
of  the  rules  interconnecting  structural  dimensions. 

•  The  choice  of  application  interface  abstraction  level  influences  the  choice  of 
notation  for  user  interface  behavior.  In  monolithic  programs  and  abstract- 
device  application  interfaces,  implicit  representation  is  usually  sufficient.  In 
toolkit  systems,  implicit  and  internal  declarative  notations  are  found  (parameters 
to  toolkit  routines  being  of  the  latter  class).  Interaction  managers  of  all  types 
use  external  and/or  internal  declarative  notations.  Extensible  interaction  man¬ 
agers  rely  heavily  on  procedural  notations,  particularly  internal  procedural  nota¬ 
tion,  since  customization  is  often  done  by  supplying  procedures. 

The  reader  may  well  have  found  these  rules  to  be  fairly  obvious  and  a  bit  boring.  This  is  an 
indication  of  the  conceptual  power  of  the  design  space:  many  useful  rules  are  immediate 
consequences  of  the  properties  of  the  chosen  dimensions.  Though  straightforward,  these 
rules  are  sufficiently  powerful  to  be  a  useful  aid  to  design. 
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4.  Automating  the  Design  Rules 

The  design  rules  are  presented  in  this  report  in  an  informal  fashion  suitable  for  use  as  guide¬ 
lines  by  human  software  designers.  It  is  also  possible  to  express  the  rules  in  a  more  de¬ 
tailed,  rigorous  formulation.  In  such  a  form  the  rules  could  be  used  as  the  basis  for  an 
automatic  design  aid.  The  author  has  experimented  with  such  automated  rules,  with 
promising  results. 

The  rules  were  expressed  in  the  form  of  numerical  weights  associated  with  particular  com¬ 
binations  of  values  along  different  dimensions.  For  example,  the  combination  of  no  external 
events  and  single  thread  of  control  received  a  positive  weight  indicating  that  a  single  thread 
of  control  may  be  a  good  choice  given  that  requirement;  while  the  combination  of  preemp¬ 
tive  external  events  and  single  thread  of  control  received  a  negative  weight.  Given  a  set  of 
functional  requirements  and  a  proposed  structural  design,  the  weights  of  the  applicable  rules 
can  be  combined  to  give  a  score  for  that  design.  A  straightforward  search  algorithm  was 
used  to  find  the  highest-scoring  design  for  a  given  set  of  requirements. 

These  automated  rules  were  tested  by  comparing  their  recommendations  to  the  actual  de¬ 
sign  choices  of  expert  human  software  designers,  as  expressed  in  a  set  of  test  cases.  A 
moderate  to  substantial  degree  of  agreement  was  observed.  This  preliminary  result  sug¬ 
gests  that  this  approach  has  considerable  potential  for  creating  practical  design  aids.  More 
immediately,  it  gives  some  confidence  that  the  design  space  described  here  captures  useful 
knowledge  about  user  interface  software  design. 

Additional  information  about  this  experiment  is  given  in  the  companion  report  [Lane  90b]. 
For  full  details,  see  [Lane  90a]. 
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5.  Summary 

This  design  space  is  directly  usable  as  a  notation  for  describing  and  comparing  user  inter¬ 
face  system  architectures.  It  should  be  useful  for  both  the  design  and  understanding  of 
systems.  The  design  rules  provide  a  good  starting  point  for  the  process  of  user  interface 
structural  design.  As  presented,  the  rules  have  been  simplified  too  much  to  be  capable  of 
making  subtle  tradeoffs,  but  they  can  still  help  a  designer  to  identify  the  better  alternatives 
and  to  reject  inappropriate  structures.  By  reducing  the  mental  effort  needed  to  make  the 
straightforward  choices,  these  rules  should  free  the  designer  to  concentrate  on  the  hard 
choices. 

An  automated  form  of  the  design  rules  has  shown  a  substantial  degree  of  agreement  with 
the  choices  of  human  designers.  One  important  implication  of  this  result  is  that  the  design 
space  provides  considerable  conceptual  leverage:  the  space  is  "right"  in  the  sense  that 
using  it  makes  choosing  an  appropriate  design  easier. 

The  design  space  and  rules  described  here  were  based  on  an  extensive  survey  of  existing 
user  interface  systems  [Lane  90a].  The  space  was  formed  by  searching  for  classifications 
that  brought  systems  with  similar  properties  together.  The  rules  were  then  prepared  on  the 
basis  of  observed  correlations.  This  process  can  be  compared  to  development  of  biological 
taxonomies  through  natural  history:  the  biologist  also  surveys  and  classifies  existing  forms, 
then  looks  for  explanatory  theories. 

At  present  there  is  no  theoretical  basis  on  which  to  argue  that  this  design  space  is  better  or 
worse  than  a  different  set  of  dimensions  that  might  be  constructed  to  describe  the  same 
systems.  The  design  space  can  be  defended  only  on  the  grounds  of  practical  utility:  it 
seems  to  capture  some  useful  design  ideas  and  correlations.  Further  experience  and  re¬ 
search  will  no  doubt  improve  this  space,  and  someday  a  more  theoretical,  rigorous  basis  for 
creating  design  spaces  may  emerge. 

Future  work  includes  refining  the  design  space  and  rules  to  cover  lower-level  choices,  thus 
providing  more  detailed  design  advice.  A  full-scale  attempt  to  automate  the  rules  might  pro¬ 
duce  a  practical  design  aid.  In  the  long  term,  we  hope  that  this  work  can  be  generalized  to 
yield  principles  of  software  architecture  that  hold  beyond  the  domain  of  user  interfaces. 
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Appendix  A:  The  Design  Space 

This  appendix  provides  a  full  description  of  the  design  space  used  in  the  experiment  with 
automated  rules.  This  space  is  probably  somewhat  different  from  what  one  would  use  in 
hand  design  work. 

The  design  space  contains  twenty-five  functional  dimensions.  Three  to  five  alternatives  are 
recognized  in  each  of  these  dimensions.  There  are  nineteen  structural  dimensions,  each 
offering  two  to  seven  alternatives. 


A.1.  Functional  Design  Dimensions 

We  turn  first  to  the  functional  design  dimensions,  which  identify  the  requirements  for  a  user 
interface  system  that  most  affect  its  structure.  These  dimensions  fall  into  three  groups: 

•  External  requirements:  Includes  requirements  of  the  particular  applications, 
users,  and  I/O  devices  to  be  supported,  as  well  as  constraints  imposed  by  the 
surrounding  computer  system. 

•  Basic  Interactive  behavior:  Includes  the  key  decisions  about  user  interface 
behavior  that  fundamentally  influence  internal  structure. 

•  Practical  considerations:  Cover  development  cost  considerations;  primarily, 
the  required  degree  of  adaptability  of  the  system. 

A.1.1.  External  Requirements 
A.1 .1.1.  Application  Characteristics 

The  characteristics  of  the  problem  domain  determine  the  features  needed  to  provide  an  ade¬ 
quate  user  interface  for  a  particular  application  or  set  of  applications.  A  general-purpose 
user  interface  system  may  support  more  than  one  of  the  alternatives  listed  for  any  of  these 
dimensions. 

Primary  output  capability.  What  will  be  the  system’s  main  means  of  communicating  infor¬ 
mation  to  its  user?  We  classify  the  alternatives  according  to  the  type  of  data  presented: 

•  Text:  Displayed  character  strings. 

•  Geometric  graphics:  Images  describable  by  geometric  elements  (lines, 
circles,  etc).  For  example,  engineering  drawings. 

•  General  images:  Images  not  readily  described  by  geometric  elements,  such  as 
scanned  photographs  or  bitmap  artwork. 

•  Voice:  Audible  speech. 

•  Audio:  Non-speech  audible  output,  such  as  music  or  tonal  signals. 

Primary  input  capability.  What  is  the  system’s  main  method  of  receiving  information  from 
its  user? 
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•  Discrete  selection:  Selection  of  one  of  a  small  set  of  alternatives;  for  example, 
selection  from  a  menu,  or  a  "yes/no H  response. 

•  Continuous  selection:  Selection  of  a  point  in  some  continuum;  for  instance 
"pointing"  to  a  point  on  a  display  surface,  or  manipulating  a  slider  or  control  dial. 

•  Text:  Textual  data,  usually  typed  on  a  keyboard;  this  is  distinguished  from  dis¬ 
crete  selection  by  a  wider  set  of  permissible  inputs.  (For  instance,  if  the  user  is 
required  to  press  y  or  n  to  answer  "yes"  or  "no,"  that  is  discrete  selection  via  a 
keyboard;  but  entry  of  prose  into  a  word  processor,  or  names  and  addresses 
into  a  mailing  list  database,  is  textual  input.) 

•  Voice,  discrete  words:  Words  are  recognized  individually,  without  use  of 
grammar  or  context  information. 

•  Voice,  connected  speech:  Full-fledged  speech  recognition,  using  semantic 
context  information  to  distinguish  ambiguous  words. 

Command  execution  time.  How  long  may  the  application  program  take  to  process  a  com¬ 
mand,  compared  with  the  reaction  time  of  a  human  user? 

•  Short  maximum  time:  All  commands  can  be  executed  in  a  short  time,  say  a 
few  tenths  of  a  second. 

•  Intermediate  maximum,  short  average:  Most  commands  are  executed  in  a 
short  time,  but  some  may  take  a  bit  longer,  up  to  a  couple  of  seconds. 

•  Long  maximum  time:  Some  or  all  commands  may  take  a  long  time  to  execute 
so  that  the  user  will  have  a  strong  perception  of  waiting. 

External  event  handling.  Does  the  application  program  need  to  respond  to  external 
events,  that  is,  events  not  originating  in  the  user  interface?  If  so,  on  what  time  scale? 

•  No  external  events:  The  application  is  uninfluenced  by  external  events,  or 
checks  for  them  only  as  part  of  executing  specific  user  commands.  For  ex¬ 
ample,  a  mail  program  might  check  for  new  mail,  but  only  when  an  explicit  com¬ 
mand  to  do  so  is  given.  In  this  case,  no  support  for  external  events  is  needed 
in  the  user  interface. 

•  Process  events  while  waiting  for  Input:  The  application  must  handle  exter¬ 
nal  events,  but  response  time  requirements  are  not  so  stringent  that  it  must  in¬ 
terrupt  processing  of  user  commands.  It  is  sufficient  for  the  user  interface  to 
allow  response  to  external  events  while  waiting  for  input. 

•  External  events  preempt  user  commands:  External  event  servicing  has  suf¬ 
ficiently  high  priority  that  user  command  execution  must  be  interrupted  when  an 
external  event  occurs. 

Error  prevention  Importance.  How  important  is  prevention  of  user  error,  relative  to  other 
goals  (such  as  speed  of  operation)? 

•  High:  Error  prevention  is  critical  to  the  task  (e.g.,  automated  banking). 
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•  Medium:  Error  prevention  is  of  intermediate  importance. 

•  Low:  Error  prevention  is  a  minor  issue. 

A.1.1.2.  User  Needs 

What  features  are  needed  for  the  intended  user  community?  The  dimensions  affecting  sys¬ 
tem  structure  are: 

User  help  needs.  How  much  user  assistance  is  provided? 

•  High:  Extensive  assistance  for  novices  is  provided. 

•  Medium:  Some  guidance  for  novices  is  provided. 

•  Low:  User  interface  is  oriented  towards  expert  users. 

User  experience  variability.  How  much  variability  in  experience  is  catered  for? 

•  High:  Different  user  interfaces  are  provided  for  novice  and  expert  users. 

•  Medium:  Minor  changes  in  behavior  are  available  for  expert  users. 

•  Low:  No  adaptation  to  different  experience  levels  is  provided. 

User  customizability.  How  much  can  a  user  modify  the  system’s  behavior?  (We  have  in 
mind  end  users,  not  application  developers.) 

•  High:  User  can  add  new  commands  and  redefine  commands  (e.g.,  via  a 
macro  language),  as  well  as  modify  user  interface  details. 

•  Medium:  User  can  modify  details  of  the  user  interface  that  do  not  . affect 
semantics;  for  instance,  change  menu  entry  wording,  default  window  sizes, 
colors,  etc. 

•  Low:  Little  or  no  user  customizability. 

A.1.1.3.  I/O  Devices 

What  types  of  I/O  devices  will  be  used  for  communication  with  the  user?  The  crucial  as¬ 
pects  for  system  structure  are: 

Device  class  breadth.  What  range  of  I/O  devices  is  supported  by  the  user  interface  soft¬ 
ware?  (We  are  interested  here  in  the  range  of  devices  that  are  considered  equivalent  at 
some  level  of  the  software;  for  example,  if  two  different  displays  are  supported,  they  are 
probably  equivalent  at  some  level,  but  a  display  and  a  speaker  would  probably  not  be  con¬ 
sidered  equivalent.) 

•  Single  device  type:  Only  a  specific  hardware  type  is  permitted. 

•  Semantically  equivalent  devices:  Devices  with  a  fixed  set  of  features  are 
permitted;  for  example,  24x80  character  terminals  with  cursor  positioning  and 
underlining  capability.  Any  additional  features  possessed  by  a  particular  device 
are  ignored.  The  means  of  invoking  the  required  features  may  vary  between 
devices. 
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•  Generic  device  definition:  A  wide  range  of  devices  is  permitted;  for  example, 
alphanumeric  terminals  of  varying  size  with  optional  color  and  highlighting  ca¬ 
pabilities. 

User  interface  adaptability  across  devices.  How  much  change  in  user  interface  behavior 
may  be  required  when  changing  to  a  different  set  of  I/O  devices? 

•  None:  All  aspects  of  behavior  are  the  same  across  all  supported  devices. 

•  Local  behavior  changes:  Only  changes  in  small  details  of  behavior  across 
devices;  for  example,  the  appearance  of  menus. 

•  Global  behavior  changes:  Major  changes  in  surface  user  interface  behavior; 
for  example,  a  change  in  basic  interface  class  (see  below). 

•  Application  semantics  changes:  Changes  in  underlying  semantics  of  com¬ 
mands  (e.g.,  continuous  display  of  state  versus  display  on  command). 

I/O  device  bandwidth.  What  data  rate  is  needed  to  support  the  user  interface  I/O  devices? 
(For  devices  with  persistent  state  such  as  displays,  use  the  burst  rate  needed  for  updates.) 

•  High:  Kilobytes  per  second  (e.g.,  high-resolution  bitmap  displays). 

•  Medium:  Hundreds  of  bytes  per  second  (e.g.,  alphanumeric  terminals). 

•  Low:  Tens  of  bytes  per  second  (e.g.,  teletypes  or  small  LED  displays). 

A.1.1.4.  Computer  System  Environment 

The  surrounding  computer  system  affects  a  user  interface  in  several  ways.  The  key  issues 
are: 

Strength  of  user  interface  conventions.  How  strong  are  the  user  interface  conventions  of 
the  computer  system? 

•  High:  Extensive,  well-defined  standards  which  are  generally  followed  (e.g.,  the 
Macintosh  user  interface  guidelines  [Apple  85]). 

•  Medium:  Conventions  exist  but  are  incomplete  and/or  often  violated  (e.g.,  Unix 
conventions  for  command  line  syntax). 

•  Low:  Little  or  no  recognized  common  user  interface  behavior.  (This  is  the  situ¬ 
ation  for  many  stand-alone  systems,  such  as  automated  store  directories.) 

Inter-application  communication  requirements.  What  kind  of  inter-application  communi¬ 
cation  is  supported  by  the  user  interface ?  ("Back  door"  communication  such  as  data  file 
exchange  is  not  counted.) 

•  None:  No  communication  at  the  user  interface  level. 

•  Data  exchange:  Via  cut-and-paste  or  standardized  I/O  formats. 

•  Program  Invokes  program:  One  program  drives  another,  issuing  commands 
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and  interpreting  responses.  (Examples  include  Unix  shell  scripts  and  various 
macro  languages.) 

Inter-application  protection  requirements.  To  what  extent  does  shared  user  interface 
software  provide  protection  boundaries  between  different  applications? 

•  High:  User  interface  deals  with  multiple  applications  and  must  prevent  undesir¬ 
able  interactions. 

•  Medium:  User  interface  deals  with  multiple  applications,  but  only  weak  protec¬ 
tion  is  needed  (e.g.,  applications  are  expected  to  cooperate). 

•  Low:  No  protection  is  needed  (typically  because  user  interface  deals  with  only 
one  application  at  a  time). 

Computer  system  organization.  What  is  the  overall  organization  of  the  computer  system? 

•  Uniprocessing:  A  single  application  executes  at  a  time. 

•  Multiprocessing:  Multiple  applications  execute  concurrently. 

•  Distributed  processing:  Network  environment,  with  multiple  CPUs  and  non- 
negligible  communication  costs. 

Existing  mechanisms  for  multiple  threads  of  control.  Does  the  operating  system  pro¬ 
vide  any  mechanism(s)  for  multiple  control  threads? 

•  Standard  processes:  Independently  scheduled  entities  with  interprocess  pro¬ 
tection  (typically,  separate  address  spaces). 

•  Lightweight  processes:  Independently  scheduled  entities  with  no  interprocess 
protection  (shared  address  space). 

•  Non-preemptlve  processes:  Processes  without  preemptive  scheduling  (must 
explicitly  yield  control);  usually  no  interprocess  protection. 

•  Interrupt  service  routines:  Hardware-level  event  handling  (a  series  of  inter¬ 
rupt  service  routine  executions  can  be  viewed  as  a  control  thread). 

•  None:  No  system  support  for  multiple  control  threads. 

Processing  power  available  for  user  Interface.  Is  adequate  processing  power  available 
for  the  user  interface,  or  is  it  necessary  to  "cut  corners"  in  the  system  design  to  achieve 
adequate  response  time? 

•  High:  Plenty  of  processing  power  is  available. 

•  Medium:  Some  care  is  needed  to  achieve  adequate  performance. 

•  Low:  Must  minimize  resources  used  by  user  interface. 

Designers  usually  make  a  rough  judgment  about  available  power  at  a  fairly  early  stage  in 
the  design  process,  and  this  judgment  colors  many  subsequent  decisions.  We  include  this 
dimension  in  the  design  space  to  make  this  judgment  explicit. 
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A. 1.2.  Basic  Interactive  Behavior 

This  group  of  dimensions  includes  the  key  decisions  about  user  interface  behavior  that  fun¬ 
damentally  influence  internal  structure.  Fortunately  these  are  few;  otherwise  a  single  struc¬ 
ture  could  not  support  a  range  of  interaction  styles. 

Basic  interface  class.  This  dimension  identifies  the  basic  kind  of  interaction  supported  by 
the  user  interface  system.  (A  general-purpose  system  might  support  more  than  one  of 
these  classes.)  The  design  space  uses  a  classification  proposed  by  Shneiderman 
[Shneiderman  86]: 

•  Menu  selection:  Based  on  repeated  selection  from  groups  of  alternatives;  at 
each  step,  the  alternatives  are  (or  can  be)  displayed. 

•  Form  filling:  Based  on  entry  (usually  text  entry)  of  values  for  a  given  set  of 
variables. 

•  Command  language:  Based  on  an  artificial,  symbolic  language;  often  allows 
extension  through  programming-language-like  procedure  definitions. 

•  Natural  language:  Based  on  (a  subset  of)  a  human  language  such  as  English. 

•  Direct  manipulation:  Based  on  direct  graphical  representation  and  incremen¬ 
tal  manipulation  of  the  program’s  data. 

It  turns  out  that  menu  selection  and  form  filling  can  be  supported  by  similar  system  struc¬ 
tures,  but  each  of  the  other  classes  has  unique  requirements. 

Degree  of  user  control  over  dialog  sequence.  How  much  control  does  the  user  have 
over  the  sequence  of  interactions  with  the  system? 

•  High:  User  controls  dialog  sequence  (e.g.,  ’’modeless"  dialog). 

•  Medium:  User  has  some  control  over  dialog. 

•  Low:  Machine  controls  dialog  sequence. 

A.1.3.  Practical  Considerations 

The  remaining  functional  dimensions  specify  the  required  degree  of  adaptability  of  the  sys¬ 
tem.  In  most  cases  a  less  adaptable  system  is  cheaper  to  build.  Vet  a  more  adaptable 
system  may  repay  its  higher  cost  by  supporting  a  wider  class  of  applications.  Another  im¬ 
portant  consideration  is  that  a  system’s  adaptability  affects  its  maintainability,  and  hence  its 
lifespan. 

It  is  useful  to  consider  adaptability  separately  for  application  code  and  user  interface  code. 
The  distinction  disappears  in  single-purpose  user  interfaces,  but  is  crucial  for  user  interface 
systems  that  support  multiple  applications.  We  use  the  term  portability  for  application  code 
and  adaptability  for  user  interface  code.  This  terminology  is  intended  to  connote  the  idea 
that  we  usually  desire  application  code  not  to  change  when  moving  from  one  environment  to 
another,  while  user  interface  support  systems  may  well  be  modified  to  better  adapt  them  to 
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new  environments.  (Of  course  there  are  exceptions  to  this  general  rule.)  Portability  implies 
that  the  application  is  unaware  of  a  change  in  environment,  or  at  least  can  handle  the 
change  without  being  rewritten. 

Application  portability  across  I/O  devices.  What  degree  of  portability  across  I/O  devices 
is  required  for  applications  that  will  use  the  user  interface  software? 

•  High:  Applications  should  be  portable  across  devices  of  radically  different 
types;  for  example,  display  versus  speech  output. 

•  Medium:  Applications  should  be  portable  across  devices  of  the  same  general 
class,  but  differing  in  detail;  for  example,  bitmap  displays  of  differing  color  capa¬ 
bilities. 

•  Low:  Device  independence  is  not  a  concern,  or  application  changes  are  ac¬ 
ceptable  to  support  new  devices. 

Application  portability  across  Interaction  styles.  What  degree  of  portability  across  user 
interface  styles  is  required  for  applications  that  will  use  the  user  interface  software? 

•  High:  Applications  should  be  portable  across  significantly  different  styles  (e.g., 
command  language  versus  menu-driven). 

•  Medium:  Applications  should  be  independent  of  minor  stylistic  variations  (e.g., 
menu  appearance). 

•  Low:  User  interface  variability  is  not  a  concern,  or  application  changes  are  ac¬ 
ceptable  when  modifying  the  user  interface. 

Application  portability  across.operating  systems.  What  degree  of  portability  across  un¬ 
derlying  computer  systems  is  required  for  applications  that  will  use  the  user  interface  soft¬ 
ware?  (Primarily  we  are  interested  in  operating  system  differences,  though  hardware  dif¬ 
ferences  may  also  be  of  interest.) 

•  High:  Applications  should  be  portable  across  significantly  different  machines 
and  operating  systems. 

•  Medium:  Applications  should  be  portable  across  related  operating  systems 
(e.g.,  portable  to  different  versions  of  Unix). 

•  Low:  System  independence  is  not  a  concern. 

User  Interface  system  adaptability  across  applications.  How  adaptable  to  different  ap¬ 
plications  should  the  user  interface  software  be? 

•  High:  Useful  across  a  wide  range  of  applications. 

•  Medium:  Useful  for  a  group  of  closely  related  applications  with  similar  interface 
needs. 

•  Low;  Supports  only  a  single  application. 
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User  Interface  system  adaptability  across  Interaction  styles.  How  adaptable  to  different 
interaction  styles  should  the  user  interface  software  be? 

•  High:  Adaptable  to  a  wide  range  of  interface  styles. 

•  Medium:  Limited  adaptability. 

•  Low:  Imposes  a  specific  interface  style. 

A  user  interface  system  may  well  be  built  to  impose  some  stylistic  decisions  on  applications; 
it  is  by  no  means  the  case  that  more  flexibility  is  always  better. 

User  interface  system  adaptability  across  operating  systems.  How  adaptable  to  differ¬ 
ent  computer  systems  should  the  user  interface  software  be? 

•  High:  Portable  across  significantly  different  machines  and  operating  systems. 

•  Medium:  Portable  across  related  operating  systems. 

•  Low:  System  independence  is  not  a  concern. 
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A.2.  Structural  Design  Dimensions 

We  now  turn  to  the  structural  dimensions,  which  represent  the  major  decisions  determining 
the  overall  structure  of  a  user  interface  system.  These  dimensions  fall  into  three  major 
groups: 

•  Division  of  functions  and  knowledge  between  modules:  How  system  func¬ 
tions  are  divided  into  modules,  the  interfaces  between  modules,  and  the  infor¬ 
mation  contained  within  each  module. 

•  Representation  issues:  The  data  representations  used  within  the  system. 

We  must  consider  both  actual  data,  in  the  sense  of  values  passing  through  the 
user  interface,  and  meta-data  that  specifies  the  appearance  and  behavior  of  the 
user  interface.  Meta-data  may  exist  explicitly  in  the  system  (for  example,  as  a 
data  structure  describing  the  layout  of  a  dialog  window),  or  only  implicitly. 

•  Control  flow,  communication,  and  synchronization  issues:  The  dynamic 
behavior  of  the  user  interface  code. 

The  structural  design  space  presented  here  is  a  simplification  of  the  complete  design  space 
discussed  in  [Lane  90a].  The  simplification  arises  primarily  from  merging  together  decisions 
that  proved  to  be  closely  correlated  in  practice.  We  will  mention  some  of  the  omitted  dimen¬ 
sions  under  the  headings  of  the  key  dimensions  with  which  they  are  associated. 

A.2.1.  Division  of  Functions  and  Knowledge 

Under  this  heading,  we  consider  how  system  functions  are  divided  into  modules,  the  inter¬ 
faces  between  modules,  and  the  information  contained  within  each  module. 

The  divisions  of  greatest  interest  are  the  divisions  between  application-specific  code  and 
shared  user  interface  code  on  the  one  hand,  and  between  device-specific  code  and  shared 
user  interface  code  on  the  other.  We  refer  to  these  divisions  as  the  application  interface  and 
device  interface,  respectively.  (See  Figure  2-1.) 

Application  Interface  abstraction  level.  The  design  space  identifies  six  general  classes  of 
application  interface.  These  classes  can  be  most  easily  distinguished  by  their  level  of  ab¬ 
straction: 

•  Monolithic  program:  There  is  no  separation  between  application-specific  and 
shared  code,  hence  no  application  interface  (and  no  device  interface,  either). 

•  Abstract  device:  The  shared  code  is  simply  a  device  driver,  presenting  an 
abstract  device  for  manipulation  by  the  application.  The  operations  provided 
have  specific  physical  interpretations  (e.g.,  "draw  line,"  but  not  "present  menu"). 

Most  aspects  of  interactive  behavior  are  under  the  control  of  the  application, 
although  some  local  interactions  may  be  handled  by  the  shared  code  (e.g., 
cnaracter  echoing  and  backspace  handling  in  a  keyboard/display  driver).  In  this 
category,  the  application  interface  and  device  interface  are  the  same. 

•  Toolkit:  The  shared  code  provides  a  library  of  interaction  techniques  (e.g., 
menu  or  scroll  bar  handlers).  The  application  is  responsible  for  selecting  appro- 
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priate  toolkit  elements  and  composing  them  into  a  complete  interface;  hence 
the  shared  code  can  control  only  local  aspects  of  user  interface  style,  with 
global  behavior  remaining  under  application  control.  The  interaction  between 
application  and  shared  code  is  in  terms  of  specific  interactive  techniques  (e.g., 
"obtain  menu  selection").  The  application  can  bypass  the  toolkit,  reaching 
down  to  an  underlying  abstract  device  level,  if  it  requires  an  interaction  tech¬ 
nique  not  provided  by  the  toolkit.  In  particular,  conversions  between  special¬ 
ized  application  data  types  and  their  device-oriented  representations  are  done 
by  the  application,  accessing  the  underlying  abstract  device  directly. 

•  Interaction  manager  with  fixed  data  types:  The  shared  code  controls  both 
local  and  global  interaction  sequences  and  stylistic  decisions.  Its  interaction 
with  the  application  is  expressed  in  terms  of  abstract  information  transfers,  such 
as  "get  command"  or  "present  result"  (notice  that  no  particular  external  repre¬ 
sentation  is  implied).  These  abstract  transfers  use  a  fixed  set  of  standard  data 
types  (e.g.,  integers,  strings);  the  application  must  express  its  input  and  output 
in  terms  of  the  standard  data  types.  Hence  some  aspects  of  the  conversion 
between  application  internal  data  formats  and  user-visible  representations 
remain  in  the  application  code. 

•  Interaction  manager  with  extensible  data  types:  As  above,  but  the  set  of 
data  types  used  for  abstract  communication  can  be  extended.  The  application 
does  so  by  specifying  (in  some  notation)  the  input  and  output  conversions  re¬ 
quired  for  the  new  data  types.  If  properly  used,  this  approach  allows  knowledge 
of  the  external  representation  to  be  separated  from  the  main  body  of  the  appli¬ 
cation. 

•  Extensible  Interaction  manager:  Communication  between  the  application 
and  shared  code  is  again  in  terms  of  abstract  information  transfers.  The  inter¬ 
action  manager  provides  extensive  opportunities  for  application-specific  cus¬ 
tomization.  This  is  accomplished  by  supplying  code  that  augments  or  overrides 
selected  internal  operations  of  the  interaction  manager.  (Most  existing  systems 
of  this  class  are  coded  in  an  object-oriented  language,  and  the  language’s  in¬ 
heritance  mechanism  is  used  to  control  customization.)  Usually  a  significant 
body  of  application-specific  code  customizes  the  interaction  manager;  this  code 
is  much  more  tightly  coupled  to  the  internal  details  of  the  interaction  manager 
than  is  the  case  with  clients  of  nonextensible  interaction  managers. 

This  classification  turns  out  to  be  sufficient  to  predict  most  aspects  of  the  application  inter¬ 
face,  including  the  division  of  user  interface  functions,  the  type  and  extent  of  application 
knowledge  made  available  to  the  shared  user  interface  code,  and  the  kinds  of  data  types 
used  in  communication.  For  instance,  we  have  already  suggested  the  division  of  local  ver¬ 
sus  global  control  of  interactive  behavior  that  is  typically  found  in  each  category. 


Variability  In  device*dependent  Interface.  The  interface  between  device-dependent  and 
device-independent  code  can  be  regarded  as  defining  an  abstract  device  for  the  device¬ 
independent  code  to  manipulate.  This  dimension  classifies  abstract  devices  according  to 
the  degree  of  variability  perceived  by  the  device-independent  code. 

•  Ideal  device:  The  provided  operations  and  their  results  are  well  specified  in 
terms  of  an  "ideal"  device;  the  real  device  is  expected  to  approximate  the  ideal 
behavior  fairly  closely. 
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•  Parameterized  device:  A  dass  of  devices  is  covered,  differing  in  specified 
parameters  such  as  screen  size,  number  of  colors,  number  of  mouse  buttons, 
etc.  The  device-independent  code  can  inquire  about  the  parameter  values  for 
the  particular  device  at  hand,  and  adapt  its  behavior  as  necessary.  Operations 
and  their  results  are  well  specified,  but  depend  on  parameter  values. 

•  Device  with  variable  operations:  A  well-defined  set  of  device  operations  ex¬ 
ists,  but  the  device-dependent  code  has  considerable  leeway  in  choosing  how 
to  implement  the  operations;  device-independent  code  is  discouraged  from 
being  closely  concerned  with  the  exact  extomai  behavior.  Results  of  operations 
are  thus  not  well  specified. 

•  Ad-hoc  device:  In  many  real  systems,  the  abstract  device  definition  has  devel¬ 
oped  in  an  ad-hoc  fashion,  and  so  it  is  not  tightly  specified;  behavior  varies  from 
device  to  device.  Applications  therefore  must  confine  themselves  to  a  rather 
small  set  of  device  semantics  if  they  wish  to  achieve  portability,  even  though 
any  particular  implementation  of  the  abstract  device  may  provide  many  addi¬ 
tional  features. 

The  reader  may  wonder  why  there  is  no  dimension  that  classifies  abstract  devices  according 
to  their  basic  functionality.  Such  a  dimension  might  use  categories  like  "bitmap  display," 
"vector  display,"  alphanumeric  display,"  "keyboard,"  "two-dimensional  locator,"  etc.  But 
there  are  a  l?;ge  number  of  such  categories,  with  no  obvious  pattern.  Moreover,  much  of 
the  useful  information  has  already  been  captured  in  other  dimensions  (device  bandwidth, 
primary  input  and  output  capability).  The  simplified  design  space  therefore  provides  no  such 
dimp-.sion. 

A.2.2.  Representation  of  Information 

Here  we  consider  the  representations  used  for  user  interface  data.  Since  we  are  studying 
overall  system  structure,  we  are  more  interested  in  representations  that  are  shared  among 
modules  than  in  those  that  are  hidden  within  a  single  module. 

Notation  for  user  Interface  definition.  This  dimension  classifies  the  techniques  used  for 
defining  user  interface  appearance  and  behavior. 

•  Implicit  in  shared  user  Interface  code:  Information  buried  within  shared 
code.  For  example,  the  visual  appearance  of  a  menu  might  be  implicit  in  the 
menu  routines  supplied  by  a  toolkit. 

•  Implicit  in  application  code:  Information  buried  in  the  application  and  not 
readily  available  to  shared  user  interface  code. 

•  External  declarative  notation:  A  nonprocedural  specification  separate  from 
the  body  of  the  application  program,  for  example,  a  grammar  or  tabular  specifi¬ 
cation.  Graphical  specification  is  an  important  special  case,  particularly  use¬ 
ful  for  specification  of  visual  appearance. 

•  External  procedural  notation:  A  procedural  specification  separate  from  the 
body  of  the  application  program;  often  cast  in  a  specialized  programming  lan¬ 
guage. 
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•  Internal  declarative  notation:  A  nonprocedural  specification  within  the  appli¬ 
cation  program.  This  differs  from  an  implicit  representation  in  that  it  is  available 
for  use  by  the  shared  user  interface  code.  Parameters  supplied  to  user  inter¬ 
face  library  routines  often  amount  to  an  internal  declarative  notation.  An  ex¬ 
ample  is  a  list  of  menu  entries  provided  to  a  toolkit  menu  routine. 

•  Internal  procedural  notation:  A  procedural  specification  within  the  application 
program.  This  differs  from  an  implicit  representation  in  that  it  is  available  for 
use  by  the  shared  user  interface  code.  A  typical  example  is  a  status-inquiry  or 
data  transformation  function  that  is  provided  for  the  user  interface  code  to  call. 

Representation  of  semantic  information.  This  dimension  classifies  the  techniques  used 
for  defining  application-specific  semantic  (as  opposed  to  external  appearance)  information 
that  is  needed  by  the  user  interface.  An  example  of  such  information  is  a  range  restriction 
on  an  input  value. 

•  Implicit:  Buried  in  the  application,  and  not  readily  available  to  shared  user  in¬ 
terface  code.  For  example,  a  range  check  carried  out  as  part  of  command  ex¬ 
ecution. 

•  Declarative:  Expressed  in  a  nonprocedural  notation;  for  example,  a  form-filling 
package  might  allow  range  limits  to  be  given  in  a  table  entry  describing  a 
numeric  input  field. 

•  Procedural:  A  procedural  specification  within  the  application  program.  This 
differs  from  an  implicit  representation  in  that  it  is  available  for  use  by  the  shared 
user  interface  code.  For  example,  a  validity  checking  subroutine  might  be  pro¬ 
vided  for  each  input  value. 

The  limited  range  of  possibilities  allowed  by  a  declarative  notation  is  more  of  a  drawback 
here  than  it  is  for  user  interface  definition.  (Semantic  information  is  inherently  more  variable 
across  applications  than  surface  user  interface  choices;  were  this  not  so,  shared  user  inter¬ 
face  behavior  would  be  of  no  interest.)  Procedural  representations  are  therefore  commonly 
used  where  shared  code  must  have  access  to  semantic  information,  while  implicit  represen¬ 
tations  are  used  where  this  can  be  avoided. 

A.2.3.  Control  Flow,  Communication,  and  Synchronization 

Here  we  consider  the  dynamic  behavior  of  the  user  interface  code.  As  with  the  previous 
group  of  dimensions,  we  are  mainly  interested  in  inter-module  communication. 

Application  control  flow.  Where  does  input  processing  occur  in  the  application's  flow  of 
control? 

•  Single  Input  point:  The  system  contains  an  event  loop  that  is  the  sole  point  at 
which  user  input  is  accepted;  when  an  input  event  is  received,  it  is  processed; 
then  control  returns  to  the  event  loop  to  await  the  next  input.  Note  that  the 
event  loop  may  be  in  either  application  or  shared  code. 

•  Multiple  input  point:  Input  is  accepted  at  multiple  points  in  the  application’s 
flow  of  control.  (Usually,  each  such  point  can  handle  only  a  subset  of  the  pos¬ 
sible  inputs,  leading  to  modal  interface  behavior.) 
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This  classification  is  a  variation  of  the  standard  distinction  between  "internal  control" 
(application  calls  user  interface)  and  "external  control"  (user  interface  calls  application) 
[Hayes  85,  Tanner  83].  The  standard  terminology  is  unsatisfactory  because  the  properties 
usually  associated  with  external  control  actually  apply  to  any  system  using  an  event  loop, 
regardless  of  the  direction  of  subroutine  calls. 

Treatment  of  asynchronous  input.  What  happens  to  user  input  actions  that  occur  while 
the  application  is  busy? 

•  Ignored:  Asynchronous  input  is  ignored. 

•  Queue  before  all  processing:  Input  events  are  queued,  but  no  processing  is 
done  (and  hence  no  feedback  occurs)  until  the  application  is  ready  for  input. 

•  Partial  processing,  simple  queue:  Some  fast  processing  is  done  to  provide 
feedback;  then  events  are  queued  for  the  application  in  a  first-in-first-out  queue. 

•  Partial  processing,  complex  queue:  As  above,  but  the  queue  may  not  be 
strictly  FIFO;  for  instance,  "abort"  commands  may  be  delivered  first,  or  may 
flush  the  queue. 

Note  that  the  first  two  of  these  alternatives  correspond  to  no  fast  input  processing,  while  the 
second  two  describe  systems  which  have  some  type  of  fast  input  processing. 

Fast  input  processing.  Is  user  input  processed  before  the  application  is  ready  to  receive 
it?  If  so,  how  flexible  is  this  processing? 

•  No  fast  processing:  Everything  is  synchronous  with  the  application. 

•  Fixed  behavior:  Some  processing  and  feedback  is  done  asynchronously;  the 
nature  of  the  asynchronous  processing  is  not  alterable  by  the  application. 
(Example:  input  echoing  and  editing  in  older  time-sharing  systems.) 

•  Parameterized  behavior:  Application-specific  code  can  set  limited  parameters 
for  the  behavior  of  the  asynchronous  processing.  For  example,  in  some  win¬ 
dow  systems,  different  cursor  shapes  can  be  established  for  different  parts  of 
an  application’s  window.  Shape  changes  are  then  handled  automatically  by  the 
cursor  tracking  code. 

•  Application-dependent  behavior:  Application-specific  code  can  be  executed 
during  fast  processing.  For  example,  an  application-specific  routine  might  be 
used  to  draw  rubber-band  feedback  images  during  dragging. 

The  more  flexible  alternatives  in  this  dimension  carry  increasing  risk  of  synchronization 
problems.  (A  simple  example  is  that  typed-ahead  characters  may  be  echoed  twice  or  not  at 
all  when  switching  between  asynchronous  echoing  and  application-driven  echoing.)  Com¬ 
munication  costs  can  also  be  a  problem  for  the  last  alternative. 

Number  of  control  threads.  How  many  control  threads  exist  in  the  application  and  user 
interface? 

•  Single  thread  of  control. 
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•  One  user  interface  thread  and  one  application  thread. 

•  Multiple  user  interface  threads  and  one  application  thread. 

•  One  user  interface  thread  and  multiple  application  threads. 

•  Multiple  user  Interface  threads  and  multiple  application  threads. 

Multiple  threads  are  useful  for  dealing  with  external  events  or  logically  independent  concur¬ 
rent  dialogues  (e.g.,  multiple  input  devices).  The  one-plus-one-thread  choice  is  particularly 
simple  and  helpful  for  decoupling  application  processing  (including  external  event  handling) 
from  user  interface  logic. 

Control  thread  mechanism.  What  mechanism,  if  any,  is  used  to  support  multiple  control 
threads? 

•  None:  Only  a  single  logical  control  thread  is  used. 

•  Standard  processes:  Independently  scheduled  entities  with  interprocess  pro¬ 
tection  (typically,  separate  address  spaces). 

•  Lightweight  processes:  Independently  scheduled  entities  within  a  shared  ad¬ 
dress  space. 

•  Non-preemptive  processes:  Processes  without  preemptive  scheduling  (must 
explicitly  yield  control),  usually  in  a  shared  address  space. 

•  Event  handlers:  Pseudo-processes  which  are  invoked  via  a  series  of  sub¬ 
routine  calls:  each  such  call  must  return  before  another  event  handler  process 
can  be  executed. 

•  Interrupt  service  routines:  Hardware-level  event  handling:  a  series  of  inter¬ 
rupt  service  routine  executions  form  a  control  thread,  but  one  with  restricted 
control  flow  and  communication  abilities.  Unlike  simple  event  handlers, 
preemptive  scheduling  is  available. 

Application  communication  grain  size.  How  frequently  does  communication  occur  be¬ 
tween  application  and  shared  user  interface  code? 

•  Fine  grain:  Roughly  once  per  user  input  event;  the  application  is  closely 
coupled  to  user  actions,  and  typically  participates  in  feedback  generation. 

•  Coarse  grain:  Roughly  once  per  complete  command:  the  application  is 
decoupled  from  user  actions  and  feedback  generation. 

Either  of  these  approaches  may  be  preferable,  depending  on  the  desired  extent  of  appli¬ 
cation  involvement  in  user  interface  details. 

Device  communication  grain  size.  How  frequently  does  communication  occur  between 
device-independent  and  device-dependent  code? 

•  Fine  grain:  Roughly  once  per  physical  input  event;  the  device-independent 
code  is  involved  in  generating  short-term  feedback  displays. 
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•  Coarse  grain:  Roughly  once  per  logical  interaction;  the  device-independent 
code  is  not  involved  in  short-term  feedback  generation. 

Basis  of  communication.  Does  communication  between  modules  depend  on  shared  state 
or  on  events,  or  both?  (An  event  is  a  transfer  of  information  occuring  at  a  discrete  time,  for 
example,  via  a  procedure  call  or  message.) 

•  Events:  There  is  no  shared  state;  all  communication  relies  on  events. 

•  Pure  state:  Communication  is  strictly  via  shared  state;  the  recipient  must 
repeatedly  inspect  the  state  variables  to  detect  changes. 

•  State  with  hints:  Communication  is  via  shared  state,  but  the  recipient  is  ac¬ 
tively  informed  of  changes  via  an  event  mechanism;  hence  polling  of  the  state 
is  not  required.  However,  the  recipient  could  ignore  the  events  and  reconstruct 
all  necessary  information  from  the  shared  state;  so  the  events  are  efficiency 
hints  rather  than  essential  information. 

•  State  plus  events:  Both  shared  state  and  events  are  used;  the  events  are 
crucial  because  they  provide  information  not  available  from  state  monitoring. 

It  is  possible  for  different  bases  of  communication  to  be  used  at  the  application  and  device 
interfaces,  but  this  is  rare.  It  is  fairly  common  to  have  different  bases  of  communication  for 
input  and  output;  hence  the  design  space  provides  separate  dimensions  for  input  and  output 
communication  basis. 

Event  mechanisms.  Unless  pure-state  communication  is  used,  a  mechanism  must  be  pro¬ 
vided  to  pass  events  between  modules.  We  classify  event  mechanisms  thus: 

•  None:  No  events  are  used  (pure  state  communication). 

•  Direct  procedure  call:  Standard  procedure-call  mechanism.  (We  include 
"remote  procedure  call"  mechanisms,  so  long  as  the  recipient  code  is  directly 
named.) 

•  Indirect  procedure  call:  Procedure  call  in  which  the  recipient  code  is  not  com¬ 
pletely  specified  by  the  calling  code,  but  is  dynamically  determined;  procedure 
pointers  and  object-oriented  method  calls  are  typical  examples. 

•  Asynchronous  message:  The  event  is  passed  from  one  control  thread  to 
another,  with  the  sender  not  waiting  for  receipt. 

•  Synchronous  message:  The  event  is  passed  from  one  control  thread  to 
another,  with  the  sender  blocked  until  the  receiver  accepts  the  message  (and 
computes  a  reply,  usually).  This  differs  from  a  remote  procedure  call  in  that  the 
receiver  is  a  separate  control  thread  that  exists  before  and  after  the  rendez¬ 
vous. 

The  procedure  call  mechanisms  are  used  for  communication  within  a  control  thread,  the 
message  mechanisms  for  communication  across  threads.  Indirect  procedure  calls  provide 
extra  separation  at  slightly  higher  cost.  Synchronous  message  mechanisms  are  somewhat 
cheaper  to  implement  than  asynchronous  ones  (for  instance,  messagv  uuffering  can  be 
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avoided),  but  they  may  create  synchronization  problems  by  increasing  timing  dependencies 
between  control  threads. 

It  is  common  to  have  different  event  mechanisms  for  input  and  output,  and  also  to  have 
different  mechanisms  at  the  application  and  device  interfaces.  Hence  the  design  space  pro¬ 
vides  four  event-mechanism  dimensions,  one  each  for  application  input,  application  output, 
device  input,  and  device  output. 

Application  separation  mechanism.  How  strongly  are  the  application  and  shared  user 
interface  code  separated? 

•  Programming  convention:  No  mechanism  exists  to  enforce  separation. 

•  Visibility  rules:  A  programming  language  mechanism  such  as  separate  name 
spaces.  Protection  strength  depends  on  whether  the  language  is  secure 
against  errors  (such  as  dangling  pointers). 

•  Hardware  separation:  A  hardware  mechanism,  typically  separate  address 
spaces.  The  shared  user  interface  code  is  reliably  protected  against  program¬ 
ming  errors  in  the  application  (and  vice  versa). 

•  Network  link:  In  addition  to  providing  hardware  separation,  the  communication 
protocol  allows  for  cross-machine  communication;  data  representation  dif¬ 
ferences  between  application  and  user  interface  code  are  supported.  An  ex¬ 
ample  is  the  support  for  varying  byte  order  in  the  X  Window  protocol. 

These  choices  provide  a  tradeoff  of  security  against  cost  of  communication.  The  availability 
of  suitable  mechanisms  is  also  a  consideration;  many  small  machines  do  not  provide 
hardware  protection  mechanisms. 

Device  separation  mechanism.  How  strongly  are  the  device-dependent  and  device¬ 
independent  layers  separated? 

The  classification  is  the  same  as  for  the  previous  dimension. 

The  data  volume  and  frequency  of  communication  are  usually  higher  here  than  at  the  appli¬ 
cation  interface,  so  the  cost  of  communication  is  a  greater  concern.  Thus  a  different  choice 
is  often  appropriate. 
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Appendix  B:  The  Design  Ruies 

This  appendix  presents  some  simple  "rules  of  thumb"  that  help  a  designer  of  user  interface 
software  to  select  a  system  architecture.  These  rules  are  not  meant  to  replace  good  design 
judgment,  but  rather  to  codify  and  speed  up  the  routine  parts  of  system  design.  The  rules 
let  the  designer  make  quick  decisions  about  aspects  of  system  structure  for  which  there  is  a 
clearly  superior  alternative,  and  they  focus  attention  on  the  most  likely  choices  in  cases 
where  more  subtle  judgment  is  necessary. 

We  discuss  the  design  dimensions  in  the  order  in  which  a  designer  might  consider  them 
while  creating  a  design.  For  each  dimension,  we  present  a  listing  of  the  considerations  that 
may  favor  or  disfavor  each  alternative,  and  some  summary  rules-of-thumb  for  selecting  one 
alternative.  Again  we  emphasize  that  these  rules  must  be  augmented  by  the  designer’s 
judgment:  typically,  the  designer  must  resolve  conflicting  suggestions  by  judging  the  relative 
importance  of  different  functional  requirements. 

Space  limitations  prohibit  any  attempt  to  provide  justifications  of  these  observations  and 
rules.  Supporting  arguments  can  be  found  in  [Lane  90a]. 


B.l.  Basic  Division  of  Functions 

The  designer's  first  order  of  business  should  be  to  define  the  overall  division  of  a  system 
into  device-specific,  shared  user  interface,  and  application-specific  parts.  We  view  this  as  a 
problem  of  specifying  two  interfaces:  the  application  interface  between  application-specific 
and  shared  code,  and  the  device  interface  between  device-specific  and  shared  code. 

B.1.1.  Application  Interface 

Application  Interface  abstraction  level.  The  design  space  identifies  six  general  classes  of 
application  interface.  In  order  of  increasing  level  of  abstraction  in  communications,  they  are: 

•  Monolithic  program:  This  is  an  appropriate  solution  in  small,  specialized  sys¬ 
tems  where  the  application  needs  considerable  control  over  Ul  details  and/or 
little  processing  power  is  available.  (Video  games  are  a  typical  example.)  This 
approach  should  not  be  chosen  if  there  are  any  strong  flexibility  requirements 
(user  customizability,  I/O  device  variability,  or  Ul  style  flexibility).  The  approach 
handles  direct  manipulation  interfaces  well,  but  application  development  effort 
will  be  high. 

•  Abstract  device:  This  approach  is  recommended  when  application  portability 
is  wanted  across  a  limited  set  of  devices,  but  most  control  of  the  user  interface 
is  to  remain  in  the  hands  of  the  application  program.  Thus  it  is  not  a  good 
choice  when  application  portability  across  Ul  styles  is  a  strong  requirement.  It 
is  best  not  to  attempt  to  support  a  very  wide  range  of  I/O  devices  with  this  ap¬ 
proach;  the  result  will  be  either  excess  development  effort  for  applications  (too 
many  cases  to  handle)  or  loss  of  control  over  Ul  details  (if  the  driver  hides  too 
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many  details).  The  characteristics  of  this  approach  are  heavily  influenced  by 
the  handling  of  abstract  device  variability,  which  is  discussed  in  Section  B.1.2. 

•  Toolkit:  Toolkits  provide  a  significant  savings  of  application  development  ef¬ 
fort,  and  yet  retain  Ul  system  flexibility  since  the  application  remains  "in  charge" 
and  can  bypass  the  toolkit  when  necessary.  By  the  same  token,  the  application 
remains  coupled  to  the  user  interface.  Therefore,  this  approach  is  recom¬ 
mended  when  a  moderate  degree  of  flexibility  is  wanted.  This  approach  is  the 
minimum  level  of  abstraction  to  use  when  a  standardized  Ul  style  is  to  be  imple¬ 
mented,  because  standard  components  (e.g.,  menus)  can  be  handled  by  toolkit 
routines  rather  than  reimplemented  by  each  application. 

•  Interaction  manager  (IM):  An  IM  is  a  good  choice  when  application  portability 
(across  devices  or  styles)  is  a  strong  requirement,  because  it  provides  a  strong 
separation  between  Ul  behavior  and  the  application  program.  A  high  degree  of 
user  customizability  can  also  be  supported.  However,  supporting  direct  manip¬ 
ulation  interfaces  is  difficult  because  the  application  cannot  supply  semantic 
feedback.  An  IM  is  useful  for  enforcing  standardized  Ul  behavior,  since  it  gives 
the  application  program  the  least  control  over  Ul  details  of  any  alternative.  An 
IM  is  especially  appropriate  in  network  environments,  because  the  IM  can  be 
physically  separated  from  the  application  with  low  communication  costs. 

•  Interaction  manager  with  extensible  data  types:  Some  IMs  provide  the  ca¬ 
pability  to  extend  the  set  of  data  types  used  for  application/I M  communication. 

This  option  allows  representation  conversion  to  be  fully  separated  from  the 
main  body  of  t,  e  application,  but  it  does  not  do  much  to  solve  the  semantic 
feedback  problem.  Hence  it  provides  only  a  small  increment  in  flexibility. 

•  Extensible  Interaction  manager:  This  is  accomplished  by  supplying  code  that 
augments  or  overrides  selected  internal  operations  of  the  IM.  An  extensible  IM 
can  provide  as  much  support  as  a  regular  IM  for  standardized  styles  of  user 
interface.  But  it  can  be  used  for  a  wider  class  of  interfaces— including  direct 
manipulation— by  taking  advantage  of  its  customization  capability.  This  ap¬ 
proach  provides  the  most  flexibility  for  meeting  user  customizability,  I/O  device 
variability,  and  Ul  style  requirements.  But  it  requires  substantial  processing 
power,  and  the  level  of  initial  investment  (for  both  Ul  system  development  and 
application  developer  training)  is  higher  than  for  any  other  alternative. 
Moreover,  care  is  needed  to  realize  the  potential  flexibility  benefits;  since 
application-specific  customization  code  sees  a  relatively  low  level  of  abstrac¬ 
tion,  it  is  easy  to  destroy  the  logical  separation  between  application  and  user 
interface  system. 

The  benefit  to  be  gained  from  building  anything  more  complex  than  an  abstract  device  sys¬ 
tem  depends  heavily  on  the  degree  of  standardization  of  Ul  behavior— that  is,  the  strength 
of  the  Ul  conventions  in  the  system  environment.  The  more  that  such  conventions  limit  the 
range  of  Ul  behavior,  the  more  functionality  can  be  put  into  a  toolkit  or  IM,  and  the  less  need 
there  is  for  an  application  to  override  standard  behavior.  Thus  increasing  strength  of  con¬ 
ventions  tilts  the  balance  first  towards  toolkits  and  extensible  IMs,  then  towards  nonexten- 
sible  IMs. 

A  nonextensible  IM  may  be  the  best  choice  when  application  portability  and  development 
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cost  are  paramount,  as  it  provides  the  most  insulation  of  the  application  from  Ul  details.  Its 
limited  range  of  Ul  styles  is  a  necessary  price;  at  least  with  present  technology,  direct  ma¬ 
nipulation  systems  cannot  be  built  without  significant  application  involvement  in  the  user  in¬ 
terface,  which  compromises  both  portability  and  cost. 

B.1.2.  Device  Interface 

The  interface  between  device-independent  and  device-specific  code  can  be  regarded  as  de¬ 
fining  an  abstract  device  for  the  device-independent  code  to  manipulate.  The  details  of  an 
abstract  device  vary  greatly  across  I/O  media,  but  some  general  statements  can  be  made 
about  the  precision  with  which  the  abstract  device  is  specified. 

Abstract  device  variability.  This  dimension  classifies  abstract  devices  according  to  the 
degree  of  variability  perceived  by  the  device-independent  code. 

•  ideal  device:  In  this  approach,  all  questions  of  device  variability  are  hidden 
from  software  above  the  device  driver  level,  so  application  portability  is  high. 

This  approach  is  most  useful  where  the  real  devices  deviate  only  slightly  from 
the  ideal  model,  or  at  least  not  in  ways  that  require  rethinking  of  Ul  behavior. 

The  ideal-device  approach  is  not  appropriate  if  any  major  changes  in  Ul  be¬ 
havior  may  be  needed  to  cope  with  differences  between  devices;  therefore  it 
cannot  cover  as  wide  a  range  of  actual  devices  as  the  other  two  approaches. 

•  Parameterized  device:  This  approach  allows  a  wide  range  of  I/O  devices  to 
be  accommodated,  and  it  permits  substantial  changes  in  Ul  behavior  across  de¬ 
vices.  The  advantage  is  that  application-specific  code  has  both  more  knowl¬ 
edge  of  acceptable  tradeoffs  and  more  flexibility  in  changing  its  behavior  than  is 
possible  for  a  device  driver.  The  drawback  is  that  device-independent  code 
may  have  to  perform  complex  case  analysis  in  order  to  handle  the  full  range  of 
supported  devices.  If  this  must  be  done  in  each  application,  the  cost  is  high 
and  there  is  a  great  risk  that  programmers  will  omit  support  for  some  devices. 

(To  reduce  this  temptation,  it  is  best  to  design  a  parameterized  model  to  have 
just  a  few  well-defined  levels  of  capability,  so  as  to  reduce  the  number  of  cases 
to  be  considered.)  This  approach  should  not  be  used  if  it  is  not  necessary  to 
support  a  wide  range  of  I/O  devices,  as  then  its  high  cost  is  not  repaid.  Less 
obviously,  it  should  not  be  used  when  high  application  portability  across  I/O  de¬ 
vices  is  crucial  (unless  the  application  is  insulated  from  the  abstract  device  by 
an  IM  layer);  the  risk  of  applications  failing  to  cover  the  full  range  of  parameter 
variation  is  too  great.  A  final  drawback  is  that  substantial  processing  power  is 
likely  to  be  needed  to  handle  extensive  runtime  case  analysis. 

•  Device  with  variable  operations:  This  approach  works  best  when  the  device 
operations  are  chosen  at  a  level  of  abstraction  high  enough  to  give  the  device 
driver  considerable  freedom  of  choice.  Hence  the  device-independent  code 
must  be  willing  to  give  up  much  control  of  Ul  details.  This  restriction  means  that 
direct  manipulation  (with  its  heavy  dependence  on  semantically-controlled 
feedback)  is  not  well  supported.  Furthermore,  only  local  changes  in  interface 
behavior  can  be  handled  at  the  device  driver  level;  changes  in  basic  interface 
class  or  application  semantics  cannot  be  supported.  When  these  restrictions 
are  acceptable,  this  approach  can  support  a  very  wide  range  of  devices  with 
little  impact  on  device-independent  code.  Its  costs  in  processing  power  are  low, 
since  runtime  case  analysis  need  not  be  performed. 
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•  Ad-hoc  device:  This  approach  is  hardly  ever  appropriate  for  new  designs.  It  is 
found  principally  in  systems  that  have  evolved  from  simpler  beginnings. 

In  systems  where  little  or  no  variation  in  I/O  devices  is  expected,  one  may  as  well  specify  an 
ideal  device  model  (tailoring  it  closely  to  the  real  devices);  this  incurs  no  runtime  cost  and 
provides  a  well-defined  picture  of  what  is  required  if  more  devices  need  to  be  supported 
later.  When  a  moderate  or  wide  range  of  I/O  devices  must  be  supported,  the  key  question  is 
what  types  of  Ul  behavior  changes  are  needed  across  devices.  Parameterization  is  essen¬ 
tial  if  global  changes  are  needed,  as  the  device  driver  cannot  handle  such  changes  alone. 
Moderate  local  changes  are  well  served  by  the  variable-operations  method,  if  its  drawbacks 
are  tolerable;  otherwise  parameterization  is  preferred.  An  ideal  device  approach  may  still  be 
usable  if  only  small,  local  changes  in  behavior  are  needed. 

It  is  possible  to  support  multiple  tradeoffs  between  handling  device  adaptation  in  the  device 
driver  and  handling  it  in  the  application:  simple  applications  can  rely  on  device-specific  Ul 
decisions  made  in  the  driver,  while  more  complex  ones  can  make  their  own  choices.  This 
amounts  to  a  combination  of  the  variable-operations  and  parameterized-device  approaches. 
Obviously,  to  make  this  work  well,  great  care  is  needed  in  defining  the  device  operations 
and  parameters. 

Selecting  the  functions  to  be  provided  in  an  abstract  device  model  is  a  complex  task.  A 
poorly  chosen  model  may  limit  portability  and/or  cause  performance  problems  due  to  mis¬ 
matches  between  its  properties  and  specific  real  devices.  Unfortunately,  good  designs 
seem  very  dependent  on  properties  of  the  particular  I/O  medium;  few  general  design  prin¬ 
ciples  have  emerged.  We  can  suggest  some  rules  of  thumb  based  on  the  chosen  degree  of 
variability.  When  using  an  ideal  or  parameterized-device  approach,  it  is  probably  best  to 
minimize  the  amount  of  user  interface  functionality  (i.e.,  representation  conversion,  se¬ 
quence  control,  user  assistance,  and  state  maintenance)  placed  in  the  device  driver.  The 
variable-operations  approach,  in  contrast,  gains  its  power  precisely  by  moving  significant 
user  interface  decisions  into  the  device  driver.  The  trick  here  is  to  choose  a  coherent  set  of 
decisions  that  are  not  tightly  coupled  to  those  remaining  in  higher  level  software.  (Some  of 
the  problems  with  GKS  input  devices  are  due  to  failure  to  maintain  this  separation 
[Rosenthal  81].) 


B.2.  Representation  Issues 

After  defining  the  major  system  components  and  allocating  functionality  among  them,  the 
next  order  of  business  is  selecting  data  representations  to  be  used  within  the  system.  We 
must  consider  both  actual  data,  in  the  sense  of  values  passing  through  the  user  interface, 
and  meta-data  that  specifies  the  appearance  and  behavior  of  the  user  interface.  Meta-data 
may  exist  explicitly  in  the  system  (for  example,  as  a  data  structure  describing  the  layout  of  a 
dialog  window),  or  only  implicitly.  We  further  subdivide  meta-data  according  to  whether  it 
bears  on  "surface"  Ul  details  or  on  deeper  questions  of  application  semantics. 
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B.2.1.  User  Interface  Definition 


Notation  for  user  interface  definition.  Here  we  consider  the  means  of  defining  Ul  appear¬ 
ance  and  behavior:  the  meta-data  that  describes  surface  details.  We  classify  notations  for 
Ul  definition  as  follows: 

•  Implicit  In  shared  user  interface  code:  This  is  simple  and  efficient;  it  is  the 
appropriate  choice  for  Ul  behavior  that  is  fixed  by  the  support  software.  In  sys¬ 
tems  where  strong  Ul  conventions  exist,  quite  a  lot  of  the  definition  can  reason¬ 
ably  be  represented  this  way.  It  should  be  avoided  when  the  user  interface 
system  is  to  be  adaptable  across  a  wide  range  of  Ul  styles,  or  when  user  cus¬ 
tomizability  is  important. 

•  Implicit  in  application  code:  This  is  the  traditional  approach  that  most  Ul 
researchers  have  tried  to  move  away  from.  But  it  will  never  be  eliminated  en¬ 
tirely  since  it,  too,  is  simple  and  efficient.  It  is  most  appropriate  where  the  appli¬ 
cation  is  already  tightly  involved  in  the  user  interface,  for  example,  in  handling 
semantic  feedback  in  direct  manipulation  systems.  It  should  be  avoided  when 
application  portability  (across  I/O  devices  or  Ul  styles)  or  user  customizability  is 
important. 

•  External  declarative  notation:  Declarative  representations  in  general  provide 
the  least  flexibility  of  interface  design,  but  are  the  easiest  to  use.  External  de¬ 
clarative  notations  are  particularly  well  suited  to  supporting  user  customization 
and  to  use  by  nonprogramming  Ul  experts.  Use  of  an  external  notation  helps 
keep  the  main  application  code  portable  across  Ul  styles  and  I/O  devices,  but 
only  if  the  notation  is  flexible  enough  to  specify  all  the  required  variations  by 
itself.  Processing  power  requirements  can  be  high,  unless  the  notation  can  be 
precompiled  in  some  way.  Graphical  specification  is  a  special  case  of  exter¬ 
nal  declarative  notation;  graphical  methods  are  particularly  appropriate  for 
specification  of  visual  appearance. 

•  Internal  declarative  notation:  From  the  application  programmer’s  viewpoint 
this  is  nearly  as  easy  to  use  as  external  declarative  notation,  and  it  requires 
much  less  supporting  mechanism;  however,  it  makes  user  customization  much 
more  difficult. 

•  External  procedural  notation:  Procedural  notations  are  more  flexible  than  de¬ 
clarative  ones,  but  are  harder  to  use.  User-accessible  procedural  mechanisms, 
such  as  macro  definition  capability  or  the  programming  language  of  EMACS- 
like  editors,  provide  very  powerful  customization  possibilities  for  sophisticated 
users.  Use  of  an  external  notation  helps  keep  the  main  application  code  port¬ 
able  across  Ul  styles  and  I/O  devices.  Substantial  processing  power  may  be 
needed,  depending  on  the  efficiency  of  the  mechanism  that  executes  the  nota¬ 
tion.  Also,  an  external  notation  by  definition  has  limited  access  to  the  state  of 
the  application  program,  which  may  restrict  its  capability. 

•  Internal  procedural  notation:  This  is  the  most  commonly  used  notation  for 
customization  of  extensible  interaction  managers.  It  provides  an  efficient  and 
flexible  notation,  but  is  not  accessible  to  the  end  user,  and  so  is  useless  for 
user  customization.  It  is  particularly  useful  for  handling  application-specific 
feedback  in  direct  manipulation  interfaces,  since  it  has  both  adequate  flexibility 
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and  efficient  access  to  application  semantics.  This  approach  is  not  favored 
when  application  portability  is  a  strong  requirement. 

Typically,  several  kinds  of  notation  are  used  in  a  user  interface  system.  Almost  always  there 
are  some  instances  of  both  kinds  of  implicit  notation,  and  one  or  more  of  the  others  is  often 
used  as  well.  The  crucial  question  is  thus  which  aspects  of  Ul  behavior  should  be  described 
in  which  kinds  of  notation.  The  best  indicators  of  the  appropriate  class  of  notation  are  the 
required  degrees  of  flexibility  and  efficiency. 

A  good  rule  of  thumb  is  that  declarative  notations  are  appropriate  for  static  information  or 
restricted  choices,  such  as  the  layout  of  a  display  or  the  selection  of  one  of  several 
predefined  behaviors.  Procedural  notations  are  a  better  choice  for  description  of  dynamic 
behavior,  because  presently  available  declarative  methods  aren’t  sufficiently  flexible.  In  ei¬ 
ther  case,  an  external  notation  should  be  used  when  user  customization  is  required;  other¬ 
wise  an  internal  notation  is  simpler  and  more  efficient.  Implicit  representation  should  be 
used  only  when  efficiency  is  crucial  or  the  probability  of  change  is  low. 

B.2.2.  Application  Semantic  Information 

Representation  of  semantic  information.  This  dimension  classifies  the  techniques  used 
for  defining  application-specific  semantic  (as  opposed  to  external  appearance)  information 
that  is  needed  by  the  user  interface.  An  example  of  such  information  is  range  restrictions  on 
an  input  value.  The  classes  are: 

•  Implicit. 

•  Declarative. 

•  Procedural. 

The  limited  range  of  possibilities  allowed  by  a  declarative  notation  is  more  of  a  drawback 
here  than  it  is  for  user  interface  definition.  (Semantic  information  is  inherently  more  variable 
across  applications  than  surface  user  interface  choices;  were  this  not  so,  shared  Ul  behavior 
would  be  of  no  interest.)  Procedural  representations  are  therefore  the  best  bet  where 
shared  code  must  have  access  to  semantic  information,  while  implicit  representations  are 
usually  used  otherwise.  In  cases  where  only  a  limited  number  of  alternatives  are  likely,  to  be 
needed,  declarative  representations  are  recommended  for  ease  of  use. 

Natural  language  interfaces  have  special  requirements:  a  great  deal  of  semantic  information 
must  be  explicitly  represented  for  use  in  disambiguating  sentences.  Both  declarative  and 
procedural  techniques  are  commonly  used. 
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B.2.3.  Representation  of  Data  Values 

It  turns  out  that  the  application  interface  class  is  usually  sufficient  to  predict  the  kinds  of  data 
types  passed  between  modules,  so  the  design  space  does  not  include  a  separate  dimension 
for  this  issue. 

The  lowest  application  interface  abstraction  levels  rely  on  device-related  data  types,  such  as 
bitmaps  or  other  image  representations  for  displays,  or  keystroke  sequences  for  keyboards. 
Toolkit  systems  introduce  data  types  for  user  interface  constructs  such  as  menus  or  scroll 
bars.  Interaction  managers  use  "internal”  data  types  that  might  be  directly  used  within  appli¬ 
cation  computations,  such  as  integer  or  floating-point  values.  Simple  I  Ms  use  a  fixed  set  of 
standard  internal  types,  while  extensible  IMs  can  be  extended  to  communicate  in  terms  of 
application-specific  internal  data  types. 

As  a  rule  of  thumb,  application-related  data  types  should  be  used  in  preference  to  device- 
related  data  types.  For  example,  integer  or  Boolean  values  are  preferred  to  equivalent 
character  strings  or  bitmaps.  This  rule  encourages  moving  representation  conversions  into 
the  user  interface  code. 


B.3.  Control  Flow  and  Synchronization 

We  turn  now  to  questions  of  control  flow:  what  are  the  control  relationships  between  the 
system  components,  and  how  are  sequences  of  events  synchronized? 

It  is  convenient  to  visualize  control  flow  in  terms  of  logical  control  threads.  A  control  thread 
is  an  entity  capable  of  independently  performing  computations  and  waiting  for  events  to  oc¬ 
cur.  We  use  this  term  in  place  of  "process”  because  we  do  not  want  to  restrict  the  notion  to 
standard  operating-system-supplied  processes.  (Section  B.5.2  lists  numerous  mechanisms 
that  can  support  the  logical  notion  of  a  control  thread,  possibly  with  some  restrictions  in 
thread  structure  or  event  response  time.) 

Application  control  flow.  Our  most  basic  control  flow  dimension  is  a  variation  of  the  stan¬ 
dard  distinction  between  "internal  control"  and  "external  control"  [Hayes  85].  We  prefer  to 
define  the  categories  as: 

•  Single  Input  point. 

•  Multiple  input  point. 

A  single  input  point  is  appropriate  for  creating  "modeless"  interfaces.  Even  with  a  moded 
interface,  building  the  application  in  single-input-point  style  can  be  helpful,  since  it  serves  to 
decouple  the  application  from  details  of  user  interface  sequencing.  Hence  high  require¬ 
ments  for  application  portability  or  user  customizability  favor  single  input  point  control  flow. 
The  major  advantage  of  multiple  input  point  flow  is  that  application  actions  need  not  be 
atomic  with  respect  to  user  interaction.  Generally,  multiple  input  points  should  be  used  only 
if  this  is  an  essential  feature. 
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A  single  input  point  is  also  desirable  when  external  events  are  to  be  handled  while  waiting 
for  user  input;  then  there  is  only  one  point  at  which  to  worry  about  external  events. 

Number  of  control  threads.  This  dimension  counts  the  control  threads: 

•  Single  thread:  This  approach  is  adequate  for  simple  systems,  particularly  if 
single  input  point  control  flow  can  be  used  (i.e.,  "external  control"  of  the  appli¬ 
cation  is  sufficient).  It  is  usually  not  appropriate  when  external  event  handling  is 
important,  nor  when  long  command  execution  times  occur. 

•  One  Ul  thread  and  one  application  thread:  This  alternative  is  very  popular 
since  it  decouples  user  interface  control  flow  from  the  application.  Two  threads 
are  sufficient  to  allow  user  interface  operations  to  execute  concurrently  with  the 
application.  On  the  user  interface  side,  this  allows  user  input  to  be  processed 
and  feedback  displays  to  be  updated  while  commands  are  being  executed.  On 
the  application  side,  external  events  can  be  handled  without  impeding  user  in¬ 
terface  response,  and  the  application  is  made  more  independent  of  user  inter¬ 
face  event  sequencing.  The  cost  of  providing  a  multiple-control-thread  mecha¬ 
nism  is  the  major  drawback  to  using  this  approach.  An  existing  control  thread 
mechanism  may  be  usable,  depending  on  the  cost  of  communication  between 
threads. 

•  Multiple  Ul  threads:  Multiple  Ul  threads  simplify  dealing  with  logically  inde¬ 
pendent  parallel  interactions.  These  occur  in  modeless  interfaces  and  when 
multiple  input  devices  are  used.  An  inexpensive  thread  mechanism  is  neces¬ 
sary  to  make  this  a  reasonable  approach. 

•  Multiple  application  threads:  Multiple  application  threads  may  be  useful  for 
dealing  with  external  events.  Some  systems  use  them  to  control  cancellation  of 
user  commands. 

If  an  inexpensive  control  thread  mechanism  is  available,  the  two-thread  approach  should  be 
used  for  all  but  the  very  simplest  user  interfaces.  The  tradeoff  point  changes  if  one  must 
build  one’s  own  thread  mechanism,  although  a  simplified  mechanism  may  be  adequate.  If 
independent  concurrent  sequences  of  events  must  be  dealt  with,  explicit  use  of  multiple 
threads  is  nearly  always  the  right  choice.  Even  with  a  restrictive  thread  mechanism,  this  will 
be  cleaner  and  more  reliable  than  ad  hoc  solutions. 

If  external  event  handling  is  required  to  preempt  user  command  execution,  a  thread  mecha¬ 
nism  that  provides  preemptive  scheduling  is  very  desirable.  Without  one,  it  will  be  neces¬ 
sary  to  poll  for  external  events  during  command  execution;  this  is  feasible,  but  inefficient  and 
error-prone. 

Treatment  of  asynchronous  Input.  The  user  interface  must  have  a  strategy  for  handling 
asynchronous  input  events  (events  that  occur  while  the  application  is  computing).  The  stan¬ 
dard  approaches  are: 

•  Ignore  asynchronous  Input:  Often  the  simplest  approach  to  implement,  and  it 
has  some  advantages  in  terms  of  simplicity  of  Ul  behavior.  It  is  usually  not 
appropriate  if  commands  may  take  a  long  time  to  execute. 
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•  Queue  before  all  processing:  A  satisfactory  solution  if  events  do  not  remain 
in  the  queue  for  long.  Otherwise,  the  lack  of  feedback  is  a  serious  human  fac¬ 
tors  shortcoming.  Hence  this  approach  is  also  inappropriate  if  commands  may 
take  a  long  time  to  execute;  but  it  is  usually  the  best  solution  for  short  or  inter¬ 
mediate  command  times. 

•  Partial  processing  with  queuing:  Provides  flexibility,  but  requires  multiple 
control  threads  and  introduces  synchronization  concerns.  Hence  it  should  be 
avoided  unless  necessary  (i.e.,  unless  there  are  long  commands). 

Fast  input  processing.  When  partial  processing  is  provided,  the  variability  of  behavior  of 
the  fast  processing  is  an  important  issue.  This  may  be: 

•  Fixed  behavior  Simple  and  has  no  synchronization  problems,  but  is  obviously 
inflexible.  It  is  sufficient  if  user  interface  system  adaptability  is  not  a  strong  re¬ 
quirement 

•  Parameterized  behavior:  Recommended  in  most  cases,  because  the 
parameter  semantics  can  be  defined  to  minimize  synchronization  problems.  (In 
particular,  one  should  be  wary  of  parameters  that  will  be  changed  "on  the  fly" 
when  already-processed  input  may  be  pending.) 

•  Application-dependent  behavior:  Should  be  used  only  if  user  interface  sys¬ 
tem  adaptability  requirements  are  so  high  as  to  make  it  mandatory.  Use  of 
application-supplied  fast  processing  routines  reduces  application  portability  and 
creates  significant  synchronization  concerns. 

The  more  flexible  alternatives  in  this  dimension  carry  increasing  risk  of  synchronization 
problems.  (A  simple  example  is  that  typed-ahead  characters  may  be  echoed  twice  or  not  at 
all  when  switching  between  asynchronous  echoing  and  application-driven  echoing.)  Com¬ 
munication  costs  can  also  be  a  problem  for  the  last  alternative.  In  general,  one  should  use 
the  least  flexible  method  possible. 

Application  communication  grain  size.  How  frequently  does  communication  occur  be¬ 
tween  application  and  shared  user  interface  code? 

•  Coarse  grain:  This  is  suitable  when  the  application  need  not  be  involved  in  the 
details  of  Ul  interactions. 

•  Fine  grain:  This  is  most  likely  to  be  required  in  direct  manipulation  interfaces. 
Communication  costs  and  application  portability  are  sacrificed,  so  this  alter¬ 
native  should  not  be  used  unless  necessary. 

Coarse-grained  communication  should  be  used  if  the  application  has  long-running  com¬ 
mands  or  external  events  to  cope  with,  since  then  one  cannot  rely  on  it  to  provide  feedback 
promptly. 

It  is  also  possible  to  distinguish  between  coarse-grained  and  fine-grained  communication  at 
the  device  interface.  In  coarse-grained  device  communication,  the  device-specific  code 
handles  feedback  for  entire  sequences  of  input  events;  while  with  fine-grained  device  corn¬ 
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munication,  feedback  is  handled  at  higher  levels.  As  a  rule  of  thumb,  fine-grained  device 
communication  is  preferable.  Coarse-grained  communication  may  be  acceptable  if  substan¬ 
tial  control  of  the  user  interface  is  to  be  put  in  the  device  driver  level;  this  is  associated  with 
the  device  interface  classification  of  abstract  devices  with  variable  operations. 

B.4.  Matters  of  State 

The  system  architecture  should  explicitly  recognize  state  information,  whether  hidden  within 
one  module  or  shared  between  modules.  Shared  state  is  a  useful  vehicle  for  communi¬ 
cation.  Shared  or  not,  the  existence  of  persistent  state  is  a  key  aspect  of  system  semantics 
and  an  important  basis  for  performance  optimization. 

B.4.1.  Representation  of  Interface  State 

How  to  represent  the  state  of  the  user  interface  is  a  very  general  question.  Our  rules  of 
thumb  address  only  a  small  part  of  it,  to  wit:  whether  to  retain  intermediate  representations 
of  output  (such  as  display  lists  or  cached  bitmaps).  Intermediate  representations  take  extra 
work  to  maintain,  but  can  provide  valuable  benefits.  We  recommend  maintaining  an  inter¬ 
mediate  output  representation  when  (1 )  the  output  device  can  usefully  be  treated  as  having 
a  state  (not  true  for  audio  output,  for  instance);  (2)  recalculating  the  output  device’s  state 
from  scratch  (from  underlying  application  state)  is  expensive;  and  (3)  partial  or  incremental 
updates  are  common.  Under  these  conditions  the  performance  gain  is  worth  the  extra 
trouble. 

Intermediate  output  representations  are  also  important  for  handling  reference  interpretation 
(e.g.,  deducing  that  a  mouse  click  represents  a  menu  element  selection).  This  may  justify 
maintaining  an  intermediate  representation  even  when  display  update  savings  are  not  signif¬ 
icant.  A  partial  representation  (e.g.,  just  menu  coordinates)  may  be  enough  for  this  purpose. 

B.4.2.  Communication  via  Shared  State 

Basis  of  communication.  Communication  between  modules  may  depend  on  shared  state 
or  on  events,  or  both.  (An  event  is  a  transfer  of  information  occuring  at  a  discrete  time,  for 
example  via  a  procedure  call  or  message.  Communication  through  shared  state  variables  is 
significantly  different  because  the  recipient  need  not  use  information  in  the  same  order  in 
which  it  is  sent.) 

•  Events. 

•  Pure  state. 

•  State  with  hlnta. 

•  State  plus  events. 

State-based  communication  can  be  recommended  for  driving  devices  that  exhibit  persistent 
state,  such  as  displays.  The  use  of  explicit  state  is  a  natural  way  of  formalizing  the  mainte- 
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nance  of  intermediate  representations  of  output  (see  above).  However,  event-based  com¬ 
munication  is  more  appropriate  for  devices  that  have  no  useful  characterization  of  state. 

The  hybrid  communication  forms  which  combine  events  with  shared  state  allow  improved 
performance  at  the  price  of  increased  complexity.  As  a  rule  of  thumb,  pure  state  systems 
are  simpler  and  less  efficient  than  pure  event  systems,  which  in  turn  are  simpler  and  less 
efficient  than  hybrid  systems. 

The  major  drawback  to  state-based  communication  is  that  it  requires  efficient  access  to 
shared  storage.  This  may  not  be  available  in  multi-process  systems,  especially  when  com¬ 
munication  across  network  links  is  involved.  Synchronization  issues  must  also  be  consid¬ 
ered  if  multiple  threads  access  the  shared  state. 


B.5.  Mechanisms 

The  final  group  of  dimensions  concern  the  mechanisms  used  to  implement  communication 
and  control  flow.  The  classifications  used  here  are  the  lowest  level  of  detail  that  can  reason¬ 
ably  be  described  as  part  of  the  system  architecture.  But  these  issues  are  indeed  part  of 
system  architecture,  because  they  have  strong  implications  for  questions  that  we  have  al¬ 
ready  discussed. 

B.5.1.  Communication  Mechanisms 

Event  mechanisms.  A  pure  state-based  system  has  no  events  and  so  needs  no  event 
communication  mechanism.  The  other  three  classes  of  communication  require  a  mecha¬ 
nism  to  pass  events  between  modules.  For  communication  within  a  single  control  thread, 
the  alternatives  are: 

•  Direct  procedure  call. 

•  Indirect  procedure  call. 

Indirect  calls  provide  useful  separation  between  the  communicating  modules.  If  the  chosen 
programming  language  has  a  natural  mechanism  for  representing  indirect  calls,  they  are 
usually  well  worth  the  small  runtime  cost;  but  otherwise  the  difficulty  of  using  indirect  calls 
may  outweigh  their  value. 

For  communication  between  control  threads,  the  alternatives  are: 

•  Asynchronous  message. 

•  Synchronous  message. 

Asynchronous  messages  are  often  superior  since  they  reduce  synchronization  problems 
and  can  be  batched  to  reduce  overhead.  Synchronous  messages  have  simpler  semantics 
and  sometimes  can  be  implemented  more  easily  (e.g.,  message  buffers  may  not  be 
needed).  If  a  message  mechanism  is  already  available,  one  should  probably  use  it  by  de¬ 
fault;  otherwise  asynchronous  messages  seem  better  suited  to  most  Ul  purposes. 
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Separation  mechanisms.  A  separation  mechanism  isolates  software  components  while 
still  permitting  communication.  We  recognize  four  classes: 

•  Programming  convention:  This  approach  provides  very  weak  protection,  but 
it  is  flexible  and  incurs  no  runtime  cost.  This  is  a  reasonable  choice  for  commu¬ 
nication  between  closely  related  components,  or  when  the  system  components 
are  automatically  generated  (and  thus  less  prone  to  human  coding  error). 

•  Visibility  rules:  This  type  of  mechanism  is  quite  flexible,  since  the  program¬ 
mer  can  choose  what  to  export  or  hide.  The  runtime  cost  is  small:  at  most,  a 
procedure  call  is  needed  to  cross  a  protection  boundary.  In  many  programming 
languages  the  protection  is  not  secure  against  runtime  errors. 

•  Hardware  separation:  Security  is  strong,  but  the  cost  of  communicating 
across  the  protection  boundary  is  high— often  several  orders  of  magnitude 
more  expensive  than  a  procedure  call.  This  is  an  appropriate  choice  when  it  is 
important  to  ensure  security,  for  example  in  a  window  manager  that  serves  mul¬ 
tiple  applications.  This  approach  may  also  be  necessary  for  communication  be¬ 
tween  modules  coded  in  different  programming  languages.  An  important 
aspect  of  hardware  separation  is  that  most  current  operating  systems  associate 
these  protection  boundaries  with  processes;  hence  division  of  the  user  interface 
system  into  protectable  entities  must  be  considered  jointly  with  control  flow  and 
synchronization  concerns. 

•  Network  link:  The  communicating  parties  can  exist  on  nonidentical  machines. 

The  cost  of  communication  in  such  a  case  is  inherently  high,  but  is  worthwhile 
in  distributed  environments. 

Generally,  visibility  rules  are  the  minimum  separation  that  should  be  used  between  appli¬ 
cation  and  user  interface  code.  Stronger  separation  mechanisms  should  be  used  only 
where  there  are  system  considerations  that  justify  their  cost.  The  major  considerations  that 
may  justify  a  stronger  mechanism  are  (1)  the  need  for  a  shared  user  interface  system  to 
protect  itself  against  errors  in  any  one  application;  (2)  use  of  a  system-provided  process 
mechanism  that  forces  hardware  separation;  or  (3)  the  desire  to  distribute  system  compo¬ 
nents  across  machines  in  a  network. 

Separation  will  also  exist  between  the  shared  user  interface  code  and  the  device-specific 
code.  This  may  or  may  not  use  the  same  class  of  mechanism  as  is  used  at  the  application 
interface.  In  most  cases  visibility  rules  are  sufficient;  the  main  exception  is  to  permit  distri¬ 
bution  across  a  network. 

B.5.2.  Control  Flow  Mechanisms 

Control  thread  mechanism.  Among  the  many  ways  to  provide  the  abstract  notion  of  a 
control  thread  are: 

•  Standard  processes:  These  provide  security  against  other  processes,  but  in¬ 
terprocess  communication  is  relatively  expensive.  For  a  user  interface  system, 
security  may  or  may  not  be  a  concern,  while  communication  costs  are  almost 
always  a  major  concern.  If  the  operating  system  already  provides  processes, 
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not  having  to  implement  one's  own  process  mechanism  is  an  important  advan¬ 
tage.  In  network  environments,  standard  processes  are  usually  the  only  kind 
that  can  be  executed  on  different  machines. 

•  Lightweight  processes:  These  are  suitable  only  for  mutually  trusting  proc¬ 
esses  due  to  lack  of  security;  but  often  that  is  not  a  problem  for  user  interface 
systems.  The  benefit  is  substantially  reduced  cost  of  communication,  espe¬ 
cially  for  use  of  shared  variables.  Few  operating  systems  provide  lightweight 
processes,  and  building  one's  own  lightweight  process  mechanism  can  be  diffi¬ 
cult. 

•  Non-preemptlve  processes:  These  are  relatively  simple  to  implement  since 
no  preemption  mechanism  is  needed.  Synchronization  can  be  achieved  merely 
by  not  yielding  the  processor,  although  explicit  interlocks  are  safer.  The  major 
drawback  is  that  response  to  I/O  devices  can  be  slow,  and  response  time  is 
hard  to  control. 

•  Interrupt  service  routines:  These  provide  a  simple  preemptive  scheduling 
mechanism.  The  control  flow  and  communication  patterns  of  ISR-implemented 
processes  are  very  restricted,  but  they  are  useful  for  ensuring  fast  response  to 
I/O  devices.  ISRs  are  highly  machine-dependent,  and  may  not  be  available  to 
unprivileged  programs. 

•  Event  handlers:  The  main  advantage  of  this  method  is  that  it  requires  virtually 
no  support  mechanism.  The  key  disadvantages  are  the  control  flow  restric¬ 
tions,  which  are  comparable  to  ISRs,  and  the  lack  of  fast  response,  which  is 
comparable  to  non-preemptive  processes. 

Of  these,  the  most  commonly  useful  alternatives  are  standard  processes,  lightweight  proc¬ 
esses,  and  event  handlers;  the  others  are  appropriate  only  in  special  cases.  For  most  user 
interface  work,  lightweight  processes  are  very  appropriate  if  available.  Standard  processes 
should  be  used  when  protection  considerations  warrant,  and  in  network  environments  where 
it  may  be  useful  to  put  the  processes  on  separate  machines.  If  these  conditions  do  not 
apply,  event  handlers  are  the  best  choice  when  their  response  time  limitations  are  accept¬ 
able;  otherwise  it  is  probably  best  to  invest  in  building  a  lightweight  process  mechanism. 


CMU/SEI-90-TR-22 


51 


References 

[Adobe  85]  PostScript  Language  Reference  Manual 

Adobe  Systems,  Inc.,  1985. 

Published  by  Addison-Wesley. 

[Apple  85]  Inside  Macintosh 

Apple  Computer,  Inc.,  1985. 

Published  by  Addison-Wesley.  Volumes  l-IV. 

[Bell  71]  C.  Gordon  Bell  and  Allen  Newell. 

Computer  Structures:  Readings  and  Examples. 

McGraw-Hill,  New  York,  1971. 

[Borenstein  88]  Nathaniel  S.  Borenstein  and  James  Gosling. 

Unix  Emacs:  A  Retrospective  (Lessons  for  Flexible  System  Design). 

In  Proceedings  of  Symposium  on  User  Interface  Software,  pages  95-101 . 
ACM  SIGGRAPH,  Banff,  Alberta,  Canada,  October  1988. 

[Dance  87]  John  R.  Dance,  Tamar  E.  Granor,  Ralph  D.  Hill,  Scott  E.  Hudson,  Jon 
Meads,  Brad  A.  Myers,  and  Andrew  Schulert. 

The  Run-time  Structure  of  U IMS-Supported  Applications. 

Computer  Graphics  21  (2):97-1 01 ,  April  1 987. 

ACM  SIGGRAPH  Workshop  on  Software  Tools  for  User  Interface  Man¬ 
agement. 

[Green  86]  Mark  Green. 

A  Survey  of  Three  Dialogue  Models. 

ACM  Transactions  on  Graphics  5(3):244-275,  July  1986. 

[Hartson  89]  H.  Rex  Hartson  and  Deborah  Hix. 

Human-Computer  Interface  Development:  Concepts  and  Systems  for  Its 
Management. 

ACM  Computing  Surveys  21(1  ):5-92,  March  1 989. 

[Hayes  85]  Philip  J.  Hayes,  Pedro  A.  Szekely,  and  Richard  A.  Lerner. 

Design  Alternatives  for  User  Interface  Management  Systems  Based  on 
Experience  with  Cousin. 

In  Proceedings  of  CHI  '85:  Human  Factors  in  Computing  Systems,  pages 
169-175.  ACM  SIGCHI,  1985. 

[Knuth  73]  Donald  E.  Knuth. 

The  Art  of  Computer  Programming.  Volume  1 :  Fundamental  Algorithms. 
Addison- Wes 'ey,  Reading,  MA,  1973. 

[Lane  90a]  Thomas  G.  Lane. 

User  Interface  Software  Structures. 

PhD  thesis,  Carnegie  Mellon  University,  May  1990. 

CMU  School  of  Computer  Science  Technical  Report  CMU-CS-90-1 01 . 
Also  available  as  Software  Engineering  Institute  Special  Report 
CMU/SEI-90-SR-13. 


CMU/SEI-90-TR-22 


53 


[Lane  90b] 

[Lantz  87] 

[Myers  89] 

[Perry  84] 

[Reid  80] 

[Rosenthal  81] 

[Rosenthal  82] 

[Scheifler  86] 

[Sedgewick  88] 

[Shaw  86] 


Thomas  G.  Lane. 

Studying  Software  Architecture  through  Design  Spaces  and  Rules. 
Technical  Report  CMU/SEI-90-TR-18,  Carnegie  Mellon  University  Soft¬ 
ware  Engineering  Institute,  October  1990. 

Also  available  as  CMU  School  of  Computer  Science  Technical  Report 
CMU-CS-90-175. 

Keith  A.  Lantz,  Peter  P.  Tanner,  Carl  Binding,  Kuan-Tsae  Huang,  and 
Andrew  Dwelly. 

Reference  Models,  Window  Systems,  and  Concurrency. 

Computer  Graphics  21  (2):87-97,  April  1 987. 

ACM  SIGGRAPH  Workshop  on  Software  Tools  for  User  Interface  Man¬ 
agement. 

Brad  A.  Myers. 

User- Interface  Tools:  Introduction  and  Survey. 

IEEE  Software  6(1  ):15-23,  January  1989. 

An  earlier  version  was  published  as  Carnegie  Mellon  University  Technical 
Report  CMU-CS-88-1 07,  January,  1988. 

Robert  H.  Perry,  Don  W.  Green,  and  James  O.  Maloney.. 

Perry's  Chemical  Engineers'  Handbook. 

McGraw-Hill,  New  York,  1984. 

Brian  K.  Reid  and  Janet  H.  Walker. 

Scribe  User's  Manual 

Third  edition,  Unilogic,  Ltd.,  May  1980. 

David  S.  H.  Rosenthal. 

Methodology  in  Computer  Graphics  Re-examined. 

Computer  Graphics  15(2):1 52-1 62,  July  1 981 . 

David  S.  H.  Rosenthal,  James  C.  Michener,  Gunther  Pfaff,  Rens  Kes- 
sener,  and  Malcolm  Sabin. 

The  Detailed  Semantics  of  Graphics  Input  Devices. 

Computer  Graphics  16(3):33-38,  July  1982. 

Robert  W.  Scheifler  and  Jim  Gettys. 

The  X  Window  System. 

ACM  Transactions  on  Graphics  5(2):79-109,  April  1986. 

Robert  Sedgewick. 

Algorithms. 

Addison-Wesley,  Reading,  MA,  1988. 

Mary  Shaw. 

An  Input-Outp"*  Model  for  Interactive  Systems. 

In  Proceedings  of  CHI  '86:  Human  Factors  in  Computing  Systems,  pages 
261-273.  ACM  SIGCHI,  1986. 


54 


CMU/SEI-90-TR-22 


[Shaw  89) 


Mary  Shaw. 

Larger  Scale  Systems  Require  Higher-Level  Abstractions. 

In  Proceedings  of  Fifth  International  Workshop  on  Software  Specification 
and  Design,  pages  143-146.  IEEE  Computer  Society,  May  1989. 
ACM  SIGSOFT  Software  Engineering  Notes,  Volume  14  Number  3. 

[Shneiderman  86]  Ben  Shneiderman. 

Seven  Plus  or  Minus  Two  Central  Issues  in  Human-Computer  Interaction. 

In  Proceedings  of  CHI  '86:  Human  Factors  in  Computing  Systems,  pages 
343-349.  ACM  SIGCHI,  1986. 

[Tanner  83]  Peter  Tanner  and  William  Buxton. 

Some  Issues  in  Future  User  Interface  Management  System  Develop¬ 
ment. 

In  Gunther  Pfaff  (editor),  Seeheim  Workshop  on  User  Interface  Manage¬ 
ment  Systems,  pages  67-79.  EUROGRAPHICS-Springer,  1983. 

[Wegner  87]  Peter  Wegner. 

Dimensions  of  Object-Based  Language  Design. 

Sigplan  Notices  22(12):1 68-182,  December  1987. 

Proceedings  of  OOPSLA  '87:  Conference  on  Object-Oriented  Program¬ 
ming  Systems,  Languages,  and  Applications. 


CMU/SEI-90-TR-22 


55 


UNLIMITED,  UNCLASSIFIED 


SCCUAI^Y  CLASSIFICATION  OF  THIS  PAGE 


1,.  acpoat  security  classification 

UNCLASSIFIED  _________ 


2^  SECURITY  CLASSIFICATION  AUTHORITY 

N/A  _  _ 


2b.  OECLASSIFICATION/OOWNGRAOING  SCHEDULE 

N/A  _ 


4  PERFORMING  ORGANIZATION  REPORT  NUMBERISI 


REPORT  DOCUMENTATION  PAGE 


lb.  RESTRICTIVE  MARKINGS 

NONE  _  _ _ 


3.  DISTRIBUTION/ AVAILABILITY  OF  REPORT 

APPROVED  FOR  PUBLIC  RELEASE 
DISTRIBUTION  UNLIMITED 


CMU/SEI-90-TR-22 


5.  MONITORING  ORGANIZATION  REPORT  NUMBERISI 

ESD-90-TR-223 


NAME  OF  PERFORMING  ORGANIZATION  Sb.  OFFICE  SYMBOL  7a  NAME  OF  MONITORING  ORGANIZATION 

(If  applicant) 

SOFTWARE  ENGINEERING  INST.  SEI  SET  .TOTNT  PROCRAM  OFFTCF. 


6c.  AOORESS  (City.  Stall  md  ZIP  Codtl 

CARNEGIE  MELLON  UNIVERSITY 
PITTSBURGH,  PA  15213 


Sa.  NAME  OF  FUNOING/SPONSORING 
ORGANIZATION 

SEI  JOINT  PROGRAM  OFFICE 


8c.  AOORESS  iCtly.  Stott  and  ZIP  Cod*) 

CARNEGIE  MELLON  UNIVERSITY 
PITTSBURGH,  PA  15213 


II.  TITLE  (Includt  Security  CUutificaiioni 


SEI  JOINT  PROGRAM  OFFICE  _ 


7b.  AOORESS  ICIly,  Stott  tn dJ,  IP. Codtl 

ESD/AVS 

HANSCOM  AIR  FORCE  BASE 

HAMCfOM  MA  01 711  _ _ 


9.  PROCUREMENT  INSTRUMENT  IDENTIFICATION  NUMBER 

F1962890C0003 


12.  PERSONAL  AUThORISI 

Thomas  G.  Lane 

13a  TYPE  OF  REPORT 


13b.  TIME  COVERED 
FROM _  TO 


10.  SOURCE  OF  FUNOING  NOS. 

PROGRAM  PROJEC1 

ELEMENT  NO.  NO. 

63752F  N/A 


14.  OATt  OF  REPORT  (Yr„  Ho.,  Doyl 

November  1990 


PROJECT 

TASK 

NO. 

NO. 

N/A 

N/A 

l  ARCHITECT 

URE 

WORK  UNIT 
NO. 


IS.  PAGE  COUNT 

62  pp. 


COSATI  COOES 


GROUP 


IS.  SUBJECT  TERMS  (Condnut  on  rtttrtt  if  met unry  and  tdtnttfy  by  btocb  numbarl 

design  methodologies  software  engineering 
design  representations  user  interfaces 

software  architecture  • _  ■- 


It.  ABSTRACT  iContmut  on  rtutm  if  ntetattry  and  idtntlfy  by  blocb  numbtn 

The  architecture  of  a  user  interface  software  system  can  be  described  in  terms  of  a  fairly 
small  number  of  key  functional  and  structural  choices.  This  report  presents  a  design 
space"  that  identifies  these  key  choices  and  classifies  the  alternatives  available  for 
each  choice.  The  design  space  is  a  useful  framework  for  organizing  and  applying  design 
knowledge.  The  report  presents  a  set  of  design  rules  expressed  in  the  terms  of  the 
design  space.  These  rules  can  help  a  software  designer  to  make  good  structural  choices 
based  on  the  functional  requirements  for  a  user  interface  system.  Extension  of  this 
work  might  eventually  provide  automated  assistance  for  structural  design. 


20.  OlSTRIBUTION/AVAILABILITY  of  abstract 


21.  ABSTRACT  SECURITY  CLASSIFICATION 


unclassifieo/unlimiteo  jj?  SAME  AS  RPT.  □  OTIC  USERS  (S  UNCLASSIFIED,  UNLIMITED  DISTRIBUTION 


22».  NAME  OF  RESPONSIBLE  INDIVIDUAL 

JOHN  S,  HERMAN,  Capt,  USAF 


22b.  TELEPHONE  NUMBER 
(Includt  A  no  Codtl 


DD  FORM  1473,83  APR 


412  268-7630 


EDITION  OF  1  JAN  73  IS  OBSOLETE. 


22c.  OFFICE  SYMBOL 

SEI  JPO _ 


UNLIMITED.  UNCLASSIFIED 

SECURITY  CLASSIFICATION  OF  THIS  PAGE 


